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20.  Abstract  (Continued) 

The  Phase  I  effort  was  conducted  to  identify  and  describe  the  current  macro¬ 
management  level  and  battlefield  functional  area  (BFA)  level  PDSS  structure 
and  processes,  relate  these  processes  to  other  Combat  Developer  functions, 
and  identify  the  Combat  Developer's  PDSS  responsibilities  and  requirements. 
Phase  I  included  review  of  organizational  responsibilities,  regulatory  and 
directive  authority,  and  the  BAS  that  must  be  supported.  Phase  I  results 
were  documented  in  the  First  Interim  Technical  Report,  Volume  II,  30  September 
1980. 

The  Second  Interim  Technical  Report,  Volume  III,  16  December  1980,  documents 
the  results  of  Phase  II.  Phase  II  was  directed  toward  defining  three  TRADOC 
functional  and  management  PDSS  systems.  The  first  of  these  systems,  the 
Baseline  System,  was  developed  from  information  gathered  and  analyzed  during 
Phase  I.  The  description  of  this  system  identifies  currently-authorized  re¬ 
sources,  and  also  projects  resource  requirements  needed  to  accomplish  future 
PDSS  using  the  present  macro-  and  BFA-level  structure.  Next,  a  Theoretical 
System,  unconstrained  by  resources,  is  described  which  would  accommodate  all 
identified  Combat  Developer  PDSS-related  functions.  Finally,  a  Hybrid  System 
is  described  recognizing  the  realities  of  current  organizational  structures 
and  their  functional  responsibilities. 

This  report  documents  Phase  III  of  the  study.  It  provides  a  description  of 
the  /Preferred"  or  M  Objective"  PDSS  System  for  TRADOC  and  an  Implementation 
Plan  for  transitioning  from  the  present  situation  to  the  Objective  System^ 

A  draft  Executive  Summary  and  Final  Report,  Volume  I,  31  January  1981,  pro¬ 
viding  an  overview  of  the  entire  study  as  described  in  the  First,  Second,  and 
Third  Interim  Reports  has  been  prepared  and  presented  to  TRADOC  for  review  and 
comment.  Following  receipt  of  the  results  of  the  TRADOC  review  an  Executive 
Summary  and  Final  Report,  Volume  I,  28  February  1981  will  be  produced  as  the 
final  effort  of  this  study. 


1 


!r)  i  D/nsz/1  -  ■  1-/01 -TH 


UNCLASSIFIED 


, ,  #•)  ,  ’  >~'iTh  ;  2 

/)/  h  'c.  £  R>i,/t , 


},/,/  l  jun 


UNITED  STATES  ARMY 

COMBINED  ARMS  COMBAT  DEVELOPMENT  ACTIVITY 


^  )  Alb  A  9«i- >  til 


ASSESSMENT  OF  THE  £0MBAT  DEVELOPER'S 
IN  POST-JiEPLOYMENT  SOFTWARE  SUPPORT  ( 
''  3j3^UNE  1 980  -  28  FEBRUARY  198T 


H ) : '  t] 


Third  Interim  Technical  Report 
Volume,  IV — - — — - 


*STRIBI#riON  5#TEMENy.  ^ 
lach  Jm&nsmiiral  or  t/iyiDcu^rilj 

JDut|/d^  of/h/  D^)ar|p?rl/^r  J/J 

-$rrns  jcJnbat  wvelomenJ^Actiintw'' 


life' 


ACN  52719 


31  JANlSi®931 


72.  •  /  •  /■ 


NOTICES 


CONTRACT  REQUIREMENT 

This  document  contains  the  Third  Interim  Technical  Report  of  the  Assessment 
of  the  Combat  Developer's  Role  in  Post-Deployment  Software  Support  (PDSS) 
under  Contract  Number  MDA903-80-C-0479  and  satisfies  the  third  requirement 
of  Contract  Data  Requirements  List  (CDRL)  Item  Number  0002AC. 


DISTRIBUTION  STATEMENT 


DISCLAIMER 

The  views,  opinions,  and  findings  contained  in  this  report  are  those  of  the 
author(s)  and  should  not  be  construed  as  an  official  Department  of  the  Army 
position,  policy,  or  decision,  unless  so  designated  by  other  official 
documentation. 


V 


ACKNOWLEDGEMENT 


This  document  is  Volume  IV  of  a  four-volume  report  produced  during  a 
study  which  was  initiated  and  sponsored  by  the  United  States  Army  Combined 
Arms  Combat  Development  Activity  (CACDA),  Foi c  Leavenworth,  Kansas  66048, 
under  Contract  Number  MDA903-80-C-0479. 

The  Contracting  Officer's  Technical  Representative  (COTR)  is  Mr.  R.  K. 
Schwabe,  JINTACCS  Office,  Army  l  /JINTACCS  Division,  Command,  Control,  Com¬ 
munications  and  Intelligence  Directorate,  Combined  Arms  Combat  Development 
Activity. 

The  BDM  Services  Company  Team  includes  L.  H.  Charity,  Program  Manager; 
J.  M.  McCurdy,  Deputy  Program  Manager;  and  the  Program  Staff,  P.  L.  Dunn, 

D.  L.  Jones,  R.  L.  Page  and  C.  J.  Thornton. 


vii 


CONTENTS 

Page 

TITLE  PAGE  .  i 

NOTICES  .  ill 

ACKNOWLEDGEMENT  .  v 

CONTENTS  .  vii 

FIGURES  .  xi 

ABSTRACT  .  xv 

SUMMARY  . xvii 

MAIN  REPORT 

CHAPTER  1.  Introduction  .  1-1 

1-1.  Statement  of  the  Problem  .  1-1 

a.  Need  for  PDSS  .  1-1 

b.  Need  for  this  Study  .  1-1 

1-2.  Background  .  1-1 

a.  Requirement  for  an  Army-Wide  PDSS  System  .  1-1 

b.  Approach  Selected  to  Satisfy  the  Requirement  -  1-1 

c.  Concept  for  Materiel  Developer  and  Combat  Developer 

Facilities  .  1-3 

1-3.  Objective  .  1-5 

a.  Overall  Study  .  1-5 

b.  Phase  III  .  1-5 

1-4.  Scope  .  1-5 

a.  General  .  1-5 

b.  Definitions  .  1-6 

c.  Relationship  of  PDSS  and  the  System  Life  Cycle  ..  1-6 

d.  Classification  .  1-8 

1-5.  Methodology  .  1-8 

a.  Study  Structure  .  1-8 

b.  Phase  I  .  1-8 

c.  Phase  II  .  1-8 


1-6 

CHAPTER  2 
2-1 
2-2 


2-3 

2-4 


2-5 


CHAPTER  3 


CONTENTS  (CONTINUED) 


d.  Phase  III  . 

e.  Final  Report  . 

Organization  of  this  Report  . 

Description  of  the  Objective  System 
General  . 


n-TO 

1-10 

1-10 

2-1 

2-1 


Principal  Factors  Influencing  System  Design  .  2-1 

a.  Assumptions  .  2-1 

b.  Design  Guidelines  .  2-2 

c.  System  Models  .  2-3 

System  Overview  .  2-8 

Concept  of  Operations  .  2-8 

a.  HQ  TRADOC  .  2-10 

b.  CACDA  .  2-10 

c.  BFA-Level  Operations  .  2-10 

d.  Principal  Interfaces  .  2-11 

Objective  PDSS  System  Components  .  2-11 

a.  General  .  2-11 

b.  Headquarters,  TRADOC  .  2-11 

c.  Combined  Arms  Combat  Development  Activity 

(CACDA)  .  2-17 

d.  Commmuni cations  Functional  Area  .  2-33 

e.  Fire  Support  BFA  .  2-55 

f.  Air  Defense  BFA  .  2-71 

g.  Intelligence  and  EW  BFA  .  2-101 

h.  Combat  Service  Support  BFA-LOGCEN  .  2-117 

i.  Combat  Service  Support  BFA-Service  Support 

Center  .  2-129 

j.  Summary  .  2-143 

Objective  System  Implementation  .  3-1 


3-1 


3-1.  General  . 

3-2.  The  Proposed  Implementation  Plan 


3-1 


CONTENTS  (CONTINUED) 


Page 


a.  Structure  of  the  Plan  .  3-1 

b.  The  Proposed  Implementation  Schedule  .  3-2 

3-3.  Actions  Required  to  Finalize  the  Plan  .  3-2 

APPENDIX  A.  Reference  Appendix  .  A-l 

APPENDIX  B.  Glossary  .  B-l 

APPENDIX  C.  Battlefield  Automated  Systems  .  C-l 

APPENDIX  D.  US  Army  Training  and  Doctrine  Command  Objective  Post-De¬ 

ployment  Software  Support  System  Implementation  Plan 
(TRADOC  PDSS  Plan)  .  D-l 


FIGURES 


Page 

1-1  Elements  of  the  battlefield  functional  area  concept  .  1-2 

1-2  Recommended  Materiel  Developer  PDSS  centers  .  1-4 

1-3  Relationship  of  PDSS  to  the  system  life  cycle  .  1-7 

1-4  PDSS  study  overview  .  1-9 

1- 5  Study  methodology  overview  .  1-11 

2- 1  Generalized  Software  Support  Model  for  PDSS  .  2-4 

2-2  CD  PDSS  Generalized  Model  1  .  2-6 

2-3  CD  PDSS  Generalized  Model  2  .  2-7 

2-4  Overview  of  the  Objective  PDSS  System .  2-9 

2-5  Principal  CD-MD-User  PDSS  interfaces  .  2-12 

2-6  HQ  TRADOC  staff  elements  with  major  responsibilities  in  the  PDSS 

System  .  2-14 

2-7  Personnel  requirements,  HQ  TRADOC .  2-15 

2-8  Estimated  personnel  costs,  HQ  TRADOC  .  2-15 

2-9  Force  Level  Control  Functional  Area  Category  1  and  2  BAS  .  2-19 

2-10  Army  C'VJINTACCS  Division  elements  with  major  PDSS 

responsibilities  .  2-20 

2-11  Army  C2/JINTACCS  Division  elements  with  major  PDSS 

responsibilities  .  2-23 

2-12  Assignment  of  functions.  Force  Control  and  Maneuver  Control 

Systems  .  2-25 

2-13  Personnel  requirements,  CACDA  .  2-30 

2-14  Breakout  of  personnel  requirements,  CACDA  .  2-30 

2-15  Estimated  personnel  costs,  CACDA  .  2-31 

2-16  USASC  &  FG  elements  with  primary  responsibilities  in  the 

Baseline  PDSS  System  .  2-35 


XT  T 


FIGURES  (CONTINUED) 

Page 

2-17  Overall  TRADOC  elements  of  Baseline  PDSS  System  for  the 

Communications  Functional  Area  .  2-36 

2-18  Systems  requiring  PDSS--Communications  Functional  Area  .  2-40 

2-19  Overview  of  Objective  POSS  System  at  USASC  .  2-42 

2-20  Software  Support  Division  (SSD)  . 2-43 

2-21  Estimated  personnel  required.  Objective  POSS  System,  Commun¬ 
ications  functional  area  .  2-50 

2-22  Estimated  personnel  required  by  element,  FY  1987  .  2-51 

2-23  Preliminary  identification  of  major  equipment  required. 

Objective  PDSS  Syste,  Communications  functional  area  .  2-52 

2-24  Estimated  funding  required,  Objective  PDSS  System,  Commun¬ 
ications  functional  area  .  2-53 

2-25  USAFACFS  elements  with  primary  responsibilities  in  the  current 

PDSS  System  .  2-56 

2-26  Category  1  and  2  systems  requiring  PDSS--Fire  Support  BFA  .  2-59 

2-27  PDSS  organizational  structure,  USAFACFS  .  2-60 

2-28  Assignment  of  functions,  Objective  PDSS  System,  Fire  Support  BFA  .  2-63 

2-29  Personnel  requirements,  USAFAS  .  2-67 

2-30  Breakout  of  personnel  requirements  by  organizational  element  .  2-67 

2-31  Estimated  personnel  costs,  USAFAS  .  2-69 

2-32  Personnel  requirements,  US  Army  Field  Artillery  Board  .  2-70 

2-33  Estimated  personnel  costs,  USAFAB  .  2-70 

2-34  TRADOC  elements  of  Baseline  PDSS  System  at  Fort  Bliss  .  2-73 

2-35  Overall  TRADOC  elements  of  Baseline  PDSS  System  for  Air  Defense 

BFA  .  2-74 

2-36  Summary  of  USAADS  mission  and  functions  .  2-75 

2-37  Systems  requiring  PDSS--Air  Defense  BFA  .  2-77 


FIGURES  (CONTINUED) 

Page 

2-38  Principal  TRADOC  &  ether  elements  in  Baseline  PDSS  System  for 

Air  Defense  BFA  .  2-78 

2-39  Principal  interfaces,  Baseline  PDSS  System,  ADA  BFA  .  2-80 

2-40  Principal  elements,  Objective  PDSS  System  for  Air  Defense  BFA  ..  2-82 

2-41  Macro-structrue  of  CD  PDSS  Objective  System  at  Air  Defense 

Center  .  2-84 

2-42  Battlefield  Systems  Software  Support  Organization  (BS30)  .  2-85 

2-43  Estimated  personnel  required,  Objective  PDSS  System,  ADA  BFA  ...  2-95 

2-44  Estimated  1987  personnel  requirements  by  element.  Objective  PDSS 

System,  Air  Defense  BFA  .  2-96 

2-45  Preliminary  identification  of  major  equipment  required.  Objective 

PDSS  System,  ADA  BFA  .  2-97 

2-46  Estimated  funding  required.  Objective  PDSS  System,  ADA  BFA  .  2-98 

2-47  Organizational  elements  with  major  responsibilities  in  the  PDSS 

Baseline  System  for  the  Intelligence  and  EW  BFA  .  2-102 

2-48  Intelligence  and  Electronic  Warfare  Category  1  and  2  BAS  .  2-104 

2-49  Concept  for  CDSF,  USAICS  .  2-107 

2-50  Assignment  of  functions,  Objective  PDSS  System,  Intelligence  and 

EW  BFA  .  2-108 

2-51  Estimated  personnel  requirements,  USAICS  .  2-113 

2-52  Breakout  of  USAICS  personnel  requirements  by  organizational 

element  .  2-113 

2-53  Estimated  personnel  costs,  USAICS  .  2-115 

2-54  Organizational  elements  with  major  responsibilities  in  the 

current  PDSS  system  for  the  Logistics  portion  of  the  CSS  BFA  ...  2-118 

2-55  Logistics  Systems  .  2-120 

2-56  Elements  of  the  Objective  PDSS  System--LOGCEN  .  2-122 

2-57  Assignment  of  functions,  Objective  PDSS  System,  Logistics  Center  2-123 


xiv 


FIGURES  (CONTINUED) 

Page 

2-58  Personnel  requirements,  LOGCEN  .  2-127 

2-59  Breakout  of  LOGCEN  personnel  requirements  by  organizational 

elements  .  2-127 

2-60  Estimated  personnel  costs,  LOGCEN  .  2-127 

2-61  TRADOC  elements  of  the  current  PDSS  System  at  SSC  .  2-131 

2-62  Overall  TRADOC  elements  of  the  current  PDSS  system  for  Personnel 

portion  of  CSS  BFA  .  2-132 

2-63  Systems  requiring  PDSS--Soldier  Support  Center  .  2-133 

2-64  Principal  TRADOC  and  other  elements  in  the  current  PDSS  system 

for  Personnel  portion  of  CSS  BFA  .  2-134 

2-65  Principal  interfaces,  current  PDSS  system,  SSC  portion  of 

CSS  BFA  .  2-135 

2-66  SSC  elements  involved  with  the  Objective  PDSS  System  .  2-137 

2-67  Principal  elements  and  interfaces  involved  in  the  Objective 

PDSS  System  for  SSC  .  2-139 

2-68  PDSS  personnel  requirements,  SSC  .  2-141 

2-69  Breakout  of  personnel  requirements  by  organizational  element  ...  2-141 

2-70  Estimate  of  funding  required,  SSC  .  2-142 

2-71  Estimated  TRADOC  personnel  requirements  by  fiscal  year  .  2-144 


ABSTRACT 


This  study  addresses  the  role  of  the  US  Army  Training  and  Doctrine  Command, 
as  the  Army's  principal  Combat  Developer,  in  planning  for  and  providing 
post-deployment  software  support  (PDSS)  to  battlefield  automated  systems 
(BAS).  The  Study  is  a  three-phase  effort  directed  toward  defining  a  viable, 
feasible,  and  cost  effective  functional  and  management  structure  for  the 
Combat  Developer  to  provide  PDSS  for  BAS,  within  the  framework  of  Army 
doctrine  and  policy,  the  Post-Deployment  Software  Support  Concept  Plan  for 
Battlefield  Automated  Systems,  and  the  related  functional  requirements  of 
the  Combat  Developer. 

The  Phase  I  effort  was  conducted  to  identify  and  describe  the  current  macro¬ 
management  level  and  battlefield  functional  area  (BFA)  level  PDSS  structure 
and  processes,  relate  these  processes  to  other  Combat  Developer  functions, 
and  identify  the  Combat  Developer's  PDSS  responsibilities  and  requirements. 
Phase  I  included  review  of  organizational  responsibilities,  regulatory  and 
directive  authority,  and  the  BAS  that  must  be  supported.  Phase  I  results 
were  documented  in  the  First  Interim  Technical  Report,  Volume  II,  30  September 
1980. 

The  Second  Interim  Technical  Report,  Volume  III,  16  December  1980,  documents 
the  results  of  Phase  II.  Phase  II  was  directed  toward  defining  three  TRADOC 
functional  and  management  PDSS  systems.  The  first  of  these  systems,  the 
Baseline  System,  was  developed  from  information  gathered  and  analyzed  during 
Phase  I.  The  description  of  this  system  identifies  currently-authorized  re¬ 
sources,  and  also  projects  resource  requirements  needed  to  accomplish  future 
PDSS  using  the  present  macro-  and  BFA-level  structure.  Next,  a  Theoretical 
System,  unconstrained  by  resources,  is  described  which  would  accommodate  all 
identified  Combat  Developer  PDSS-related  functions.  Finally,  a  Hybrid  System 
is  described  recognizing  the  realities  of  current  organizational  structures 
and  their  functional  responsibilities. 

This  report  documents  Phase  III  of  the  study.  It  provides  a  description  of 
the  "Preferred"  or  "  Objective"  PDSS  System  for  TRADOC  and  an  Implementation 
Plan  for  transitioning  from  the  present  situation  to  the  Objective  System. 

A  draft  Executive  Summary  and  Final  Report,  Volume  I,  31  January  1981,  pro¬ 
viding  an  overview  of  the  entire  study  as  described  in  the  First,  Second,  and 
Third  Interim  Reports  has  been  prepared  and  presented  to  TRADOC  for  review  and 
comment.  Following  receipt  of  the  results  of  the  TRADOC  review  an  Executive 
Summary  and  Final  Report,  Volume  I,  28  February  1981  will  be  produced  as  the 
final  effort  of  this  study. 
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SUMMARY 


1.  INTRODUCTION. 

a.  General .  The  US  Army  has  spent,  is  spending,  and  wi1!  spend  many 
billions  of  dollars  on  sophisticated  battlefield  systems.  The  automated  com¬ 
ponents  of  many  of  these  systems  have  increased  rapidly  in  just  a  few  years 
to  the  point  where  automation  represents  a  very  substantial,  and  in  some  cases 
the  major,  portion  of  system  costs.  The  military  value  of  such  systems,  in 
terms  of  combat  effectiveness  and  combat  readiness,  cannot  be  realized  unless 
individual  systems  perform  as  intended  by  the  user  and  the  many  interdepen¬ 
dent  systems  interoperate  as  an  integrated  whole.  Achievement  of  such  objec¬ 
tives  is  a  problem  of  system  planning,  integration,  management,  and  support— 
throughout  the  system  life  cycle.  This  study  addresses  a  critical  part  of 
this  total  problem— that  part  dealing  with  post-deployment  software  support 
(PDSS) . 


b.  The  PDSS  Requirement.  The  requirement  to  provide  PDSS  to  the  growing 
number  of  battlefield  automated  systems  (BAS)  projected  to  enter  the  Army 
inventory  during  the  next  several  years  is  one  of  increasing  concern  within 
the  Army.  The  Users,  Materiel  Developer  (MD),  and  Combat  Developer  (CD)  all 
have  essential  roles  in  the  total  effort  to  provide  effective  PDSS  for  BAS. 
The  US  Army  Training  and  Doctrine  Command  (TRADOC),  as  the  Army's  principal 
CD  and  the  "battlefield  architect",  is  responsible  for  determining  what  cap¬ 
ability  is  required  and  when  it  is  required.  This  CD  responsibility  applies 
to  initial  system  development  and  to  any  subsequent  post-deployment  changes 
to  a  system.  In  carrying  out  this  role,  the  CD  must  be  a  driver,  innovator, 
and  active  representative  of  all  Field  Users. 

2.  PURPOSE.  The  purpose  of  this  three-phase  study  is  to  define,  in  detail, 
a  viable,  feasible,  and  cost  effective  functional  and  management  structure 
through  which  the  CD  can  fulfill  his  role  in  providing  PDSS  for  BAS  within 
the  framework  of  Army  doctrine  and  policy,  the  Army  PDSS  Concept  Plan  for 
BAS  and  the  related  functional  requirements  of  the  CD. 

3.  DISCUSSION. 

a.  Background. 

(1)  Requirement  for  an  Army-Wide  PDSS  System.  Recognizing  the  in¬ 
creasing  importance  of  PDSS,  the  US  Army  Materiel  Development  and  Readiness 
Command  (DARCOM)  initiated  a  study  in  May  1978,  directed  toward  developing  a 
concept  for  a  systematic  approach  to  planning  for  and  providing  PDSS  for  BAS 
on  an  Army-wide  basis  in  accordance  with  guidance  from  the  US  Army  Vice  Chief 
of  Staff.  A  task  force  of  representatives  from  the  Army  Staff  and  several 
Army  commands  was  formed  to  assist  DARCOM  in  this  effort.  Results  of  the 
effort  are  documented  in  a  report  entitled  PDSS  Concept  Plan  for  BAS,  May 
1980.  Both  DARCOM  and  TRADOC  have  concurred  in  this  report  which  has  been 
forwarded  to  Headquarters,  Department  of  the  Army  (HQDA)  for  approval. 
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(2)  Approach  Selected  to  Satisfy  the  Requirement.  The  approach 
selected  for  providing  PDSS  to  the  Army's  BAS,  and  documented  in  the  PDSS  Con¬ 
cept  Plan  cited  above,  focuses  on  the  battlefield  functional  area  (BFA)  concept 
since  it  is  within  each  BFA  that  the  doctrinal,  functional,  and  technical  de¬ 
pendencies  and  interoperability  needs  are  the  greatest.  This  approach  calls 
for  MD-managed  PDSS  centers  to  be  located  at  five  TRADOC  doctrinal  centers/ 
schools  and  at  six  materiel  developing  commands,  as  discussed  in  Chapter  1. 

This  approach  recognizes  both  the  doctrinal  sensitivity  of  certain  BAS  and  the 
inherently  technical  complexity  of  others.  This  approach  requires  a  case-by¬ 
case  review  of  systems  and  a  separate  decision  as  to  the  optimal  location(s) 
for  fielded  software  support  for  each.  It  is  designed  to  achieve  the  software 
support  benefits  resulting  from  BFA  orientation  while  recognizing  the  real¬ 
ities  of  current  organizational  structures  of  DARCOM  and  TRADOC,  and  the  func¬ 
tional  responsibilities  of  the  US  Army  Intelligence  and  Security  Command 
(INSCOM),  the  US  Army  Communications  Command  (USACC),  and  the  US  Army  Computer 
Systems  Command  (USACSC). 

(3)  Implementation.  Both  DARCOM  and  TRADOC  are  proceeding  with 
actions  directed  toward  the  further  development  and  implementation  of  the 
concept  plan  cited  above.  This  study  represents  the  initial  part  of  the 
implementation  effort  within  TRADOC. 


b.  Assumptions. 


(1 )  Missions  and  PDSS  Roles. 


(a)  The  mission  and  basic  role  of  the  MD  with  respect  to  PDSS 
will  remain  essentially  as  described  in  the  PDSS  Concept  Plan  for  BAS,  May 
1980. 


(b)  The  mission  and  basic  role  of  the  CD  with  respect  to  PDSS 
will  remain  essentially  as  described  in  the  PDSS  Concept  Plan  for  BAS,  May 
1980,  and  the  First  Interim  Technical  Report  of  the  Assessment  of  the  Combat 
Developer's  Role  in  Post-Deployment  Software  Support,  30  September  1980. 

(c)  The  major  functional  responsibilities  of  TRADOC  centers  and 
schools  will  remain  essentially  as  specified  in  TRADOC  Reg.  10-41  and  the  re¬ 
spective  center  and  school  organization  and  functions  regulations. 

(2)  PDSS  Centers.  Materiel /System  Developer-managed  PDSS  Centers 
will  be  established  as  recommended  in  the  PDSS  Concept  Plan  for  BAS,  May 
1980.  The  11  recommended  centers  are  identified  in  Chapter  1. 

(3)  BAS.  BAS  addressed  in  this  report  will  continue  to  be  developed 
and  enter  the  Army  inventory  through  1987,  generally  as  currently  projected. 
These  BAS  are  identified  in  Appendix  C. 
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c.  Methodology. 

(1)  Study  Structure.  This  study  is  to  be  completed  through  the 
accomplishment  of  eight  tasks  over  an  eight  month  period  divided  into  three 
phases.  The  study  began  30  June  1980  and  is  scheduled  to  be  completed  28 
February  1981. 

(2'  Phase  I.  Phase  I  began  upon  contract  award.  It  consisted  of 
Tasks  1  through  4.  It  addressed  the  current  structure  and  processes  within 
the  Army  at  the  macro-  and  BFA- levels  for  performing  PDSS,  and  identified 
the  Combat  Developer's  PDSS  requirements  at  the  BFA  level.  Results  of  Phase 
I  were  documented  in  the  First  Interim  Technical  Report,  30  September  1980. 

(3)  Phase  II.  Phase  II  of  the  study,  which  consisted  of  Tasks  5,  6, 
and  7,  was  directed  toward  the  definition  of  the  TRADOC  Baseline  PDSS  System 
and  two  alternative  TRADOC  PDSS  models  or  systems  that,  if  implemented,  would 
provide  TRADOC  a  better  capability  to  accomplish  its  PDSS  role.  These  systems 
were  developed  from  the  PDSS  information  gained  during  Phase  I,  from  SAG 
member  feedback,  and  from  further  analysis  and  research  during  this  Phase  II 
effort.  These  alternatives  were  reviewed  by  TRADOC  at  a  SAG  Meeting,  17-18 
December  1980,  to  derive  and  provide  guidance  for  the  design  of  a  preferred 

or  "objective"  PDSS  functional  and  management  system. 

(4)  Phase  III.  Following  receipt  of  guidance  from  the  Phase  II  SAG 
meeting,  the  Phase  III  study  effort  proceeded.  The  Phase  III  effort  was  de¬ 
voted  to  the  development  of  the  design  and  a  description  of  the  "Objective" 
PDSS  System,  and  a  plan  which  would  provide  for  transition  from  the  present  to 
to  implementation  of  the  selected  alternative  model.  This  Objective  System 
design  and  the  Implementation  Plan  are  documented  in  this  Third  Interim 
Technical  Report. 

(5)  Final  Report.  An  Executive  Summary  and  Final  Report  is  to  be 
prepared  and  submitted  in  draft  on  31  January  and  in  final  copy  on  28 
February  1981. 

d.  Analysis. 

(1)  The  Objective  PDSS  System.  The  TRADOC  Objective  PDSS  System 
presented  in  this  report  was  designed  by  the  Study  Team  based  on  guidance 
provided  by  the  Study  Advisory  Group  (SAG),  following  its  review  of  the 
TRADOC  PDSS  Baseline,  Theoretical,  and  Hybrid  System  alternatives  which  were 
presented  at  the  Phase  II  SAG  Meeting,  17-18  December  1980.  This  Objective 
PDSS  System  incorporates  desirable  features  and  capabilities  of  the  organiz¬ 
ational  structure  and  operating  procedures  of  the  current  Baseline  as  well 
as  the  proposed  Theoretical  and  Hybrid  System  alternatives  developed  during 
Phase  II.  The  result  is  an  Objective  System,  tailored  to  the  PDSS-capabil ity 
requirements  of  HQ  TRADOC  and  each  integrating  and  functional  center  with 
significant  Combat  Developer  (CD)  responsibilities  for  battlefield  automated 
systems  (BAS).  This  Objective  PDSS  System  design  provides  for: 


•  A  POSS  Staff  Element  at  Headquarters,  TRADQC  to  provide  a  focal 
point  for  PDSS  at  the  major  command  level  and,  in  conjunction  with 
the  HQ  TRADOC  CD  "hardware  directorates",  to  coordinate  and  exer¬ 
cise  staff  supervision  over  PDSS  matters  within  TRADOC 

•  PDSS  Staff  Elements  at  CACDA  to  provide  a  capability  to  fulfill 
assigned  responsibilities  as  the  TRADOC  PDSS  proponent  and 
principal  integrating  center  and  as  proponent  of  the  CCS^  concept 

•  A  PDSS  capability  at  the  seven  major  TRADOC  doctrinal  centers  that 
have  proponency  for  functional  area  components  of  the  BFA  concept 

•  A  Combat  Developments  System  Manager  (CDSM)  for  each  BAS  that  has 
reached  Milestone  II  in  the  system  development  cycle  (or  a  compar¬ 
able  point  for  systems  being  developed  under  other  (e.g.,  evolu¬ 
tionary)  concepts).  The  CDSM  is  to  be  the  CD  software  developer 
and  principal  Field  User  representative  for  PDSS  of  a  specified 
system  or  group  of  systems  within  a  BFA 

•  Provision  for  maintaining  liaison  between  the  CD  and  those 
geographically  separated  MD  PDSS  Centers  with  which  the  CD  must 
interact  regularly  in  planning  and  providing  PDSS  for  BAS  for  which 
the  MD  and  CD  each  have  major  responsibilities  in  their  respective 
functional  areas. 

The  design  of  this  Objective  PDSS  System  provides  an  appropriate  degree  of 
uniformity  and  commonality  throughout  the  system  while  recognizing  the  need 
for  certain  differences  among  system  components  because  of  variations  in 
both  current  capability  and  current  and  future  requirements  for  PDSS  at  the 
various  centers  and  schools.  The  full  implementation  and  effective  manage¬ 
ment  of  this  Objective  PDSS  System  would  provide  HQ  TRADOC  and  subordinate 
commands  an  adequate  capability  to  fulfill  their  roles  and  responsibilities 
in  planning  and  providing  PDSS  for  BAS  currently  projected  for  deployment 
through  1987. 

(2)  The  Implementation  Plan.  The  proposed  Implementation  Plan  in 
Appendix  D  covers  those  principal  actions  or  events  that  need  to  be  accom¬ 
plished  during  the  initial  (approximately  one  year)  period  of  this  TRADOC  im¬ 
plementation  effort,  from  March  1981  through  March  1982.  If  this  schedule 
is  maintained,  other  actions  originating  from  these  initial  actions  will  then 
continue  on  for  several  years  before  full  implementation  is  achieved. 
Throughout  this  implementation  period  and  beyond,  a  number  of  actions  associ¬ 
ated  with  the  TRADOC  Resources  Management  System  (TRADOC  Pam  11-11)  and  the 
Priorities  and  Tasking  Control  Process  (TRADOC  Reg.  11-2)  must  be  accomplished 
on  a  recurring  basis. 
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CHAPTER  1 
INTRODUCTION 


1-1.  STATEMENT  OF  THE  PROBLEM. 

a.  Need  for  PDSS.  The  ever-increasing  complexity  and  magnitude  of  the 
requirement  to  provide  post-deployment  software  support  (PDSS)  to  the  growing 
number  of  battlefield  automated  systems  (BAS)  projected  to  enter  the  Army  in¬ 
ventory  during  the  next  several  years  is  of  major  concern  within  the  Army. 

The  US  Army  Training  and  Doctrine  Corranand  (TRADOC),  as  the  Army's  principal 
Combat  Developer  (CD)  and  the  "battlefield  architect",  has  a  key  role,  togeth¬ 
er  with  the  Materiel  Developer  (MD),  and  system  User,  in  the  total  effort  to 
provide  effective  PDSS  for  BAS.  Fulfilling  this  responsibility  necessitates 
that  the  CD  interact  continuously  with  both  the  User  and  MD  to  ensure  that 
capabilities  are  fully  employed  and  User  requirements  are  realized  to  the 
maximum  extent  possible.  In  carrying  out  this  role,  the  CD  must  be  a  driver, 
innovator,  initiator,  and  active  representative  of  all  Field  Users. 

b.  Need  for  this  Study.  Within  this  general  concept,  the  specific 
role  of  the  CD  in  the  evolving  Army  system  for  providing  PDSS  to  BAS  must  be 
defined.  The  functional  and  management  structure  and  the  resource  require¬ 
ments  necessary  to  enable  the  CD  to  carry  out  this  role  must  be  identified 
and  addressed  in  an  Implementation  Plan  that  will  provide  for  transitioning 
from  the  current  situation  to  achievement  of  the  required  capability  to 
provide  PDSS.  This  study  is  the  first  step  in  moving  toward  the  acquisition 
of  this  required  capability. 

1-2.  BACKGROUND. 

a.  Requirement  for  an  Army-Wide  PDSS  System.  Recognizing  the  require¬ 
ment  for  an  improved  capability  to  provide  timely,  effective  PDSS  to  BAS,  the 
US  Army  Materiel  Development  and  Readiness  Command  (DARCOM)  initiated  a  study 
in  May  1978,  directed  toward  developing  a  concept  for  a  systematic  approach 
to  planning  for  and  providing  PDSS  for  BAS  on  an  Army-wide  basis  in  accor¬ 
dance  with  guidance  from  the  US  Army  Vice  Chief  of  Staff.  A  task  force  of 
representati ves  from  the  Army  Staff  and  several  Army  commands  was  formed  to 
assist  DARCOM  in  this  effort.  Results  of  the  effort  are  documented  in  a 
report  entitled  PDSS  Concept  Plan  for  BAS,  May  1980.  Both  DARCOM  and  TRADOC 
have  concurred  in  this  report  which  has  been  forwarded  to  Headquarters, 
Department  of  the  Army  (HQDA)  for  approval. 

b.  Approach  Selected  to  Satisfy  the  Requirement.  The  task  force  that 
conducted  the  DARCOM-initiated  study,  cited  above,  considered  several  alter¬ 
native  approaches  for  providing  PDSS  to  the  large  number  of  BAS  projected  for 
deployment  over  the  next  few  years.  The  approach  selected,  and  documented 

in  the  PDSS  Concept  Plan  for  BAS,  focuses  on  the  battlefield  functional  area 
(BFA)  since  it  is  within  each  BFA  that  the  doctrinal,  functional,  and  technical 
dependencies  and  interoperability  needs  are  the  greatest.  Figure  1-1  illus¬ 
trates  the  elements  included  in  the  BFA  concept.  In  consonance  with  this 


i 


Figure  1-1.  Elements  of  the  battlefield  functional  area  concept 


concept,  an  approach  for  providing  PDSS  to  BAS,  called  the  "hybrid  approach", 
was  selected.  This  approach  calls  for  MD-managed  PDSS  centers  to  be  located 
at  five  TRADOC  doctrinal  centers/schools  and  at  six  developing  commands.  This 
hybrid  approach  recognizes  both  the  doctrinal  sensitivity  of  certain  BAS  and 
the  inherently  technical  complexity  of  others.  In  addition,  it  provides  for 
the  modular  separation  of  systems  which  are  both  highly  technical  and  tacti¬ 
cally  sensitive  and  which  should,  ideally,  be  supported  at  more  than  one 
location.  This  approach  requires  a  case-by-case  review  of  systems  and  a 
separate  decision  as  to  the  optimal  location(s)  for  fielded  software  support 
for  each.  It  is  designed  to  achieve  the  software  support  benefits  resulting 
from  BFA  orientation  while  recognizing  the  realities  of  current  organizational 
structures  of  DARCOM  and  TRADOC,  and  the  functional  responsibilities  of  the 
US.Army  Intelligence  and  Security  Command  (INSCOM),  the  US  Army  Communications 
Command  (USACC),  and  the  US  Army  Computer  Systems  Command  (USACSC). 

c.  Concept  for  Materiel  Developer  and  Combat  Developer  Facilities.  The 
hybrid  approach,  discussed  above,  recognizes  the  need  for  both  MD  and  CD 
facilities  for  PDSS.  The  number  and  location  of  MD  facilities  are  addressed 
specifically  in  the  PDSS  Concept  Plan  for  BAS;  however,  CD  facilities  are  only 
addressed  conceptually. 

(1)  Materiel  Developer  facilities.  With  respect  to  MD  facilities, 
the  plan  recommends  the  establishment/maintenance  of  11  PDSS  software  support 
centers  as  shown  in  Figure  1-2.  As  indicated  in  the  figure,  four  of  these 
centers  are  currently  operational,  although  some  expansion  may  be  desirable. 

The  establishment  of  PDSS  centers  at  Fort  Bliss,  Fort  Sill,  Fort  Leavenworth, 
and  Fort  Huachuca,  as  provided  for  in  the  PDSS  Concept  Plan  for  BAS,  satisfies 
TRADOC' s  requirement  that  the  PDSS  centers  for  executive/control  systems  be 
located  with  the  CD  to  provide  synergism  between  the  User  and  the  PDSS  center. 

(2)  Combat  Developer  facilities.  The  PDSS  Concept  Plan  for  BAS 
outlines  a  concept  for  establishing  CD  facilities  to  provide  for  the  close  and 
continuous  relationship  which  must  exist  between  the  CD  and  MD  throughout  a 
system's  life  cycle.  This  concept  calls  for  the  designation  of  Combat  Develop¬ 
ment  System  Managers  (CDSM)  and  the  establishment  of  Combat  Development  Support 
Facilities  (CDSF)  as  determined  to  be  needed  by  TRADOC.  The  definitions  of 
these  terms  are  presented  below,  as  developed  during  this  current  study  effort. 


(a)  Combat  Development  System  Manager  (CDSM).  CDSM  is  a  term 
used  to  identify  the  member  of  TRADOC  who  is  assigned  primary  responsibility 
as  the  software  Combat  Developer  and  the  principal  Field  User's  representative 
for  PDSS  of  a  designated  system  or  group  of  systems  within  a  BFA.  The  CDSM  is 
responsible  for  managing/conducting  and  coordinating  all  software-related 
actions  inherent  in  the  CD  mission.  A  CDSM  will  be  designated  by  the  commander 
of  the  responsible  center  or  school  for  every  BAS  for  which  TRADOC  has  pro- 
ponency,  prior  to  the  attainment  of  Milestone  II  in  the  system  life  cycle.  The 
CDSM  will  normally  remain  in  existence  until  the  system(s)  for  which  he  is  re¬ 
sponsible  are  phased  out  of  operation.  The  CDSM  may  be  any  combat  developments 
staff  officer  deemed  to  be  capable  of  fulfilling  the  responsibilities  of  the 
CDSM  for  a  given  system  or  systems.  This  could  be  a  TRADOC  System  Manager  (TSM) 
or  a  member  of  the  TSM's  staff  if  desired. 
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MATERIEL  DEVELOPER  PDSS 

CENTERS 

CENTER 

LOCATION 

MANAGED  BY 

1 

PICATINNY  ARSENAL 

ARRADCOM 

2 

FORT  MONMOUTH 

CORADCOM 

3 

FORT  LEAVENWORTH 

CORADCOM 

4 

FORT  BELVOIR* 

CSC 

5 

FORT  LEE* 

CSC 

6 

FORT  BLISS* 

MI  COM 

7 

FORT  SILL* 

CORADCOM 

8 

FORT  HUACHUCA 

ERADCOM 

9 

FORT  MONMOUTH 

ERADCOM 

10 

REDSTONE  ARSENAL 

MI  COM 

11 

FORT  MONMOUTH 

AVRADCOM 

|  *Currently  operational 

Figure  1-2.  Recommended  Materiel  Developer 
PDSS  centers 
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(b)  Combat  Development  Support  Facility  (CDSF).  CDSF  is  a 
;  term  used  to  identify  the  collection  of  facilities,  equipment,  personnel, 

!  and  operating  procedures  which  provide  a  CD  focal  point  for  addressing  PDSS 

and  related  matters  and  together  represent  the  capability  of  a  TRADOC  inte¬ 
grating  or  functional  center  to  fulfill  its  responsibilities  in  planning 
■  and  providing  PDSS  for  BAS.  This  embodiment  of  the  Combat  Developer's  PDSS 

capability  may  exist,  in  whole  or  in  part,  at  a  specific  location  on  a  con¬ 
tinuous  basis  as  a  specifically  identified  part  of  the  TRADOC  center's 
organizational  structure  or  may  be  formed  on  an  ad  hoc  basis  from  resources 
integral  to  various  organizational  elements  of  the  center.  A  CDSF  may  exist 
or  be  formed  as  needed  through: 

|  •  TRADOC  participation  in  the  associated  DARCOM  PDSS  facility  (either 

physically  or  electronically) 

•  Use  of  other  existing  TRADOC  resource 

•  Development  of  separate  facilities  collocated  with  DARCOM  PDSS 
facilities 

•  Development  of  separate  facilities  not  associated  with  DARCOM  PDSS 
facilities. 

The  prominence  and  permanency  of  CDSFs  may  vary  among  TRADOC  integrating  and 
functional  centers  depending  upon  differences  in  the  magnitude  of  PDSS  re¬ 
quirements  and  local  organizational  structure  and  operating  procedures.  The 
nature  of  the  CDSF  at  any  given  center  may  also  vary  from  time  to  time  depend 
ing  upon  changes  in  PDSS  requirements,  e.g.,  changes  in  the  number  or  life 
cycle  stage(s)  of  battlefield  automated  systems  for  which  the  center  has  pro- 
ponency. 

1-3.  OBJECTIVE. 

'  a.  Overall  Study.  The  objective  of  this  three-phase  study  is  to 

define,  in  detail,  a  viable,  feasible,  and  cost  effective  functional  and 
management  system  through  which  the  CD  can  fulfill  his  role  in  providing  PDSS 
for  BAS  within  the  framework  of  Army  doctrine  and  policy,  the  Army  PDSS 
Concept  Plan  for  BAS  and  the  related  functional  requirements  of  the  CD. 

b.  Phase  III.  The  objective  of  Phase  III,  addressed  in  this  report  is 
,  to  integrate  the  results  of  Phases  I  and  II  into  an  Implementation  Plan  for 

"  ;  ,  the  CD  PDSS  model  or  system  selected  by  the  Government  at  the  end  of  Phase  II 

\  Achievement  of  this  objective  requires  the  development  of  a  description  of 

’  f  the  preferred  TRADOC  PDSS  functional  and  management  system  and  a  plan  for 

'  transitioning  from  the  present  to  implementation  of  the  preferred  system. 

\  1-4.  SCOPE. 

a.  General .  This  study  focuses  upon  TRADOC 's  role  as  the  Army's 
•  principal  CD,  in  planning  for  and  providing  PDSS  for  BAS.  The  BAS  to  be 

addressed  are  listed  in  Appendix  C,  organized  by  BFA.  While  all  BAS  listed 
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are  being  considered,  the  study  effort  is  being  focused  primarily  on  Category 
1  and  2  BAS  in  accordance  with  Study  Advisory  Group  (SAG)  guidance  documented 
in  the  minutes  of  the  first  SAG  meeting  held  on  14  August  1980. 

b.  Definitions.  Several  definitions  are  listed  below  to  further 
clarify  this  scope. 

(1)  Post- Deployment  Software  Support  (PDSS)  .  PDSS  is  that  part  of 
overall  system  support  necessary  to  sustain,  modify,  and  improve  a  deployed 
system's  computer  software,  as  defined  by  the  User  or  his  representative.  It 
includes  evaluation,  development,  and  timely  implementation  of  system  and  soft 
ware  modifications  to  accommodate  trouble  reports;  User  proposed  changes;  and 
changes  to  satisfy  new  or  revised  doctrinal,  tactical,  procedural  or  interoper 
ability  requirements.  PDSS  is  discussed  further  in  Paragraph  c.,  below. 
(Source:  Reference  3.,  Appendix  A.) 

(2)  Battlefield  Automated  System  (BAS).  A  BAS  is  a  system  which 
contains  a  computer(s),  is  intended  for  use  by  the  Army  in  the  field,  and 
which  will  not  function  without  computer(s);  e.g.,  AN/TSQ-73,  TACFIRE. 

(Source:  Reference  76.,  Appendix  A.) 

(3)  Battlefield  Functional  Area  (BFA).  A  BFA  is  a  conceptual 
grouping  of  Army  personnel,  equipment,  and  procedures  which  together  perform 
a  major  battlefield  function.  The  BFAs  used  in  this  study  are  identified  in 
Figure  1-1.  (Source:  Reference  9.,  Appendix  A.) 

c.  Relationship  of  PDSS  and  the  System  Life  Cycle.  Planning  for  and 
provision  of  PDSS  must  be  accomplished  as  an  integral  part  of  system  develop¬ 
ment  and  life  cycle  management.  The  CD's  PDSS  planning  effort  begins  with 
participation  in  preparation  of  the  Computer  Resources  Management  Plan  (CRMP) 
during  the  Conceptual  Phase.  This  effort  continues  throughout  the  remaining 
system  development  phases.  This  planning  effort  is  illustrated  in  Figure  1-3. 
It  should  be  noted  that  the  system  life  cycle  illustrated  in  this  figure  has 
been  adapted  from  that  contained  in  DA  Pamphlet  11-25  and  also  that  used  in 
the  PDSS  Concept  Plan  for  BAS,  May  1980.  Consequently,  there  are  differences 
between  this  figure  and  the  system  life  cycle  described  in  AR  18-1,  August 
1980,  but  the  two  can  be  generally  related  through  the  milestones  identified. 
Also  shown  in  Figure  1-3  is  the  period  when  CD  PDSS  actions  may  occur.  The 
time  when  the  actions  begin  will  vary  among  systems  but  it  is  generally 
accepted  that  CD  PDSS-type  actions  may  be  required  any  time  after  the  system 
software  configuration  is  frozen  for  engineering  development.  This  initiation 
of  PDSS-type  actions  normally  occurs  near  Milestone  II  (from  a  point  slightly 
before  start  of  engineering  development  to  a  point  slightly  before  DT/OT  II) 
in  the  development  cycle  as  shown  in  Figure  1-3.  Thereafter,  the  CD  may  be 
involved  with  PDSS  actions  t  iroughout  the  remainder  of  the  system  life  cycle. 
Any  changes  before  the  system  software  configuration  is  frozen  are  considered 
to  be  part  of  system  development,  not  PDSS.  For  those  systems  being  developed 
under  the  evolutionary  concept  authorized  by  DOD  Instruction  5000.2,  PDSS 
planning  must  begin  early  in  the  conceptual  stage.  PDSS  actions  for  these 
evolutionary  systems  will  be  required  beginning  with  the  deployment  of  the 
initial  developmental  version. 


Figure  1-3.  Relationship  of  PDSS  to  the  system  life  cycle 
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d.  Cl  ass  if ication.  Contract  No.  MDA903-80-C-0479  under  which  this 
study  is  being  conducted  states  that,  "The  highest  classification  involved  ! 

in  the  performance  of  this  contract  is  SECRET."  No  systems  whose  existence  ] 

is  classified  within  this  level  were  identified  to  the  study  team  during  I 

the  Phase  I  or  Phase  II  research  efforts.  If  there  are  systems  whose  exis¬ 
tence  is  classified  above  the  SECRET  level,  TRADOC  PDSS  requirements  ' 

associated  with  such  systems  must  be  identified  and  addressed  separately. 

1-5.  METHODOLOGY.  * 

a.  Study  Structure.  Within  the  scope  described  in  Paragraph  1-4,  „ 

this  study  is  to  be  completed  through  the  accomplishment  of  eight  tasks  over 

an  eight  month  period  divided  into  three  phases  as  shown  in  Figure  1-4.  This 
figure  also  illustrates  the  relationship  between  the  tasks  and  phases  of  the 
study.  The  study  began  30  June  1980  and  is  scheduled  to  be  completed  28 
February  1981. 

b.  Phase  I.  Phase  I  began  upon  contract  award.  It  consisted  of  Tasks 
1  through  4. 

(1)  Task  1 .  The  Work  Plan  prepared  during  Task  1  was  delivered  to 
the  Contracting  Officer's  Technical  Representative  (COTR)  on  17  July  1980. 

This  plan  was  then  presented  to  and  approved  by  the  SAG  at  its  initial  meeting 
on  14  August  1980. 

(2)  Tasks  2,  3  and  4.  The  First  Interim  Technical  Report  documents 
the  results  of  the  Phase  I  effort,  devoted  to  Tasks  2,  3,  and  4,  which  began 
in  early  July  and  ended  on  30  September  1980.  These  tasks  addressed  macro¬ 
management  level  PDSS  processes,  BFA-level  PDSS  processes,  and  TRADOC' s  BFA- 
level  PDSS  requirements.  After  presentation  and  review,  the  SAG  approved 
this  report  at  its  second  meeting,  8  October  1980. 

c.  Phase  II.  Phase  II  of  the  study,  documented  in  the  Second  Interim 
Technical  Report  and  consisting  of  Tasks  5,  6,  and  7,  was  directed  toward 
the  definition  of  the  TRADOC  Baseline  PDSS  System  and  two  alternative  TRADOC 
PDSS  models  or  systems  that,  if  implemented,  would  provide  TRADOC  a  better 
capability  to  accomplish  its  PDSS  role.  These  systems  were  developed  from 
the  PDSS  information  gained  during  Phase  I,  f rom  SAG  member  feedback,  and 

from  further  analysis  and  research  during  Phase  II.  A  written  description  ^ 

of  the  Baseline  System  was  prepared  first,  as  a  basic  point  o/  reference. 

One  of  the  two  alternative  systems,  called  the  Theoretical  System,  was  then 
designed  to  satisfy  all  CD  PDSS  responsibilities,  without  reference  to  any  4 

resource  constraints  except  that  it  be  a  potentially  achievable  alternative. 

This  Theoretical  System  was  structured  and  a  written  description  was  prepared, 
working  primarily  from  the  BFA  center  level  upwards.  Then  the  Baseline  and 
Theoretical  Systems  were  compared  and  analyzed  for  insights  on  which  to  base 
the  design  of  the  second  of  the  two  alternative  systems,  called  the  Hybrid 
System.  Phase  II  results  were  presented  orally  at  the  SAG  Meeting  on  17-18 
December  1980. 
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d.  Phase  III.  Following  presentation  of  the  TRADOC  PDSS  alternatives 
by  the  Study  Team  at  the  Phase  II  SAG  meeting  on  17-18  December  1980,  and  de¬ 
tailed  discussion  of  each  alternative,  SAG  members  provided  additional  general 
guidelines  relative  to  an  overall  concept  for  a  preferred  TRADOC  PDSS  system 
and  more  specific  guidance  for  structuring  each  component  of  the  system. 
Principal  features  of  this  concept  and  guidance  were  provided  to  the  Study  Team 
orally  and  by  informal  notes  and  working  papers  during  and  following  the  SAG 
meeting.  Key  elements  of  guidance  were  also  provided  subsequently  in  the 
minutes  of  the  SAG  meeting.  Based  on  the  guidance  received,  the  Study  Team 
proceeded  to  develop  a  detailed  description  of  the  Preferred  TRADOC  PDSS  Alter¬ 
native  System  and  to  identify  and  describe  key  elements  of  an  implementation 
plan.  The  sequence  of  effort  and  principal  events  during  this  and  previous 
phases  of  the  study  are  illustrated  in  Figure  1-5.  The  description  of  the 
Preferred  TRADOC  PDSS  Alternative  System,  which  will  be  subsequently  referred 
to  as  the  "Objective  PDSS  System"  and  the  Implementation  Plan  are  presented  in 
Chapters  2  and  3  of  this  report,  respectively. 

e.  Final  Report.  A  Final  Report  is  to  be  submitted  in  draft  on  31 
January  1981,  revised  following  government  review,  and  submitted  in  final  copy 
on  28  February  1981. 

1-6.  ORGANIZATION  OF  THIS  REPORT.  The  remainder  of  this  report  is  organized 
to  provide  a  description  of  the  TRADOC  Objective  PDSS  System  (Chapter  2)  and 
to  discuss  features  of  implementation  planning  (Chapter  3).  Appendices  A,  B, 

C,  and  D  contain,  respectively,  the  References,  Glossary,  battlefield  automated 
systems  addressed  in  this  study,  and  a  Draft  Implementation  Plan. 


P 


Figure  1-5.  Study  methodology  overv 


CHAPTER  2 


DESCRIPTION  OF  THE  OBJECTIVE  SYSTEM 

2-1.  GENERAL.  This  chapter  contains  a  description  of  the  TRADOC  Objective 
Post-Deployment  Software  Support  (PDSS)  System.  This  description  has  been 
developed  by  the  Study  Team  based  on  guidance  provided  by  the  Study  Advisory 
Group  (SAG),  following  its  review  of  the  TRADOC  PDSS  Baseline,  Theoretical, 
and  Hybrid  System  alternatives  which  were  presented  at  the  Phase  II  SAG 
Meeting,  17-18  December  1980.  This  Objective  PDSS  System  incorporates  desir¬ 
able  features  and  capabilities  of  the  organizational  structure  and  operating 
procedures  of  the  current  Baseline  as  well  as  the  proposed  Theoretical  and 
Hybrid  System  alternatives  developed  during  Phase  II.  The  result  is  an  Objec¬ 
tive  System,  tailored  to  the  PDSS-capabil ity  requirements  of  HQ  TRADOC  and 
each  integrating  and  functional  center  with  significant  Combat  Developer  (CD) 
responsibilities  for  battlefield  automated  systems  (BAS).  The  design  of  this 
Objective  PDSS  System  provides  an  appropriate  degree  of  uniformity  and  common¬ 
ality  throughout  the  system  while  recognizing  the  need  for  certain  differences 
among  system  components  because  of  variations  in  both  current  capability  and 
current  and  future  requirements  for  PDSS  at  the  various  centers  and  schools. 

The  full  implementation  and  effective  management  of  this  Objective  PDSS  System 
would  provide  HQ  TRADOC  and  subordinate  commands  an  adequate  capability  to 
fulfill  their  roles  and  responsibilities  in  planning  and  providing  PDSS  for 
BAS  currently  projected  for  deployment  through  1987.  This  chapter  discusses 
the  design  guidelines  and  other  factors  having  a  significant  influence  on 
system  design  and  the  generalized  models  on  which  the  functional  and  management 
structure  of  each  system  component  is  based.  It  also  provides  an  overview  of 
the  system,  a  general  description  of  the  concept  of  operations,  and  a  descrip¬ 
tion  of  each  principal  system  component. 

2-2.  PRINCIPAL  FACTORS  INFLUENCING  SYSTEM  DESIGN. 

a.  Assumptions.  Common  assumptions  on  which  the  design  of  this  system 
is  based  are  presented  below.  Other  assumptions  applicable  to  individual 
system  components  are  included  in  Paragraph  2-5. 

(1 )  Missions  and  PDSS  roles. 

(a)  The  mission  and  basic  role  of  the  Materiel  Developer  (MD) 
with  respect  to  PDSS  will  remain  essentially  as  described  in  the  PDSS  Concept 
Plan  for  BAS,  May  1980. 

(b)  The  mission  and  basic  role  of  the  CD  with  respect  to  PDSS 
will  remain  essentially  as  described  in  the  PDSS  Concept  Plan  for  BAS,  May 
1980,  and  the  First  Interim  Technical  Report  of  the  Assessment  of  the  Combat 
Developer's  Role  in  Post-Deployment  Software  Support,  September  30,  1980. 

(c)  The  major  functional  responsibilities  of  TRADOC  centers 
and  schools  will  remain  generally  as  specified  in  TRADOC  Reg.  10-41  and  the 
respective  center  and  school  organization  and  functions  regulations. 
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(2)  PDSS  Centers.  Materiel /System  Developer-managed  PDSS  centers 
will  be  established  as  recommended  in  the  PDSS  Concept  Plan  for  BAS,  May  1980. 
The  11  recommended  centers  were  identified  in  Figure  1-2. 

(3)  BAS.  BAS  addressed  in  this  report  will  continue  to  be  developed 
and  enter  the  Army  inventory  through  1987,  generally  as  currently  projected. 
These  BAS  are  identified  in  Appendix  C. 

b.  Design  Guidelines. 

(1)  Relationship  of  PDSS  to  TRADOC  mission  and  functions.  Within 
TRADOC,  PDSS  is  to  be  performed  as  an  integral  part  of  the  system  development 
and  life  cycle  management  process  under  the  combat  developments  mission. 

(2)  Relationship  of  PDSS  to  operational  concepts.  The  system  to 
be  established  for  performing  PDSS  is  to  be  in  consonance  with: 

(a)  TRADOC 's  operational  and  management  concept  of  centralized 
management  and  decentralized  control  and  operations,  as  described  in  AR  10-41 
and  TRADOC  Regs.  10-5  and  10-41. 

(b)  The  Battlefield  Functional  Area  (BFA)  Concept  discussed 

in  Chapter  1 . 

o 

(c)  The  Command,  Control,  and  Subordinate  Systems  (CCS  ) 
concept  currently  promulgated  within  TRADOC. 

(d)  The  PDSS  Concept  Plan  for  BAS,  May  1980. 

(3)  Relationship  among  centers  and  schools.  Relationships  among 
PDSS  organizational  elements  at  the  various  centers  and  schools  will  be 
governed  by  the  existing  integrating  center  -  associated  center  and  school 
concept  discussed  in  TRADOC  Reg.  10-41.  PDSS  elements  of  key  centers  and 
schools  should  be  interconnected  by  appropriate  means  to  facilitate  the  co¬ 
ordination  and  interaction  that  must  occur  among  these  centers  and  schools 
in  managing  the  major  command  and  control  BAS  under  the  CCS^  concept. 

(4)  Organizational  structuring.  Within  the  common  design  guide¬ 
lines  set  forth  in  this  chapter,  the  PDSS  system  elements  at  each  center 
and  school  may  be  individually  tailored  to  best  accomplish  local  PDSS  re¬ 
quirements.  The  extent  to  which  a  center  and  school's  PDSS  capability  is 
integrated  into  the  existing  organizational  structure  as  opposed  to  being 

a  separately  identified  organizational  element  may  vary  based  upon: 

(a)  Current  capabilities  to  fulfill  PDSS  responsibilities 

(b)  The  number,  nature,  and  life  cycle  stage  of  BAS  for  which 
the  center  and  school  is  responsible 
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(c)  Relationship  to  an  associated  MD-managed  PDSS  Center 

(d)  Desires  and  objectives  of  each  center  and  school  commander. 

(5)  System  implementation.  This  PDSS  system  represents  an  objec¬ 
tive  to  be  achieved  by  1987  through  the  accomplishment  of  implementation 
actions  integrated  with  the  Army's  Planning,  Programming,  and  Budgeting  (PPBS) 
cycle.  Resource  requirements  should  be  identified  as  needed  begining  in  1981 
although  the  FY  83  budget  and  the  FY  84-88  Program  Objective  Memorandum  (POM) 
provide  the  earliest  opportunity  for  addressing  these  requirements  in  the 
programming  and  budgeting  process. 

c.  System  Models 

(1)  Generalized  Software  Support  Model  for  PDSS.  The  Task  Force 
that  prepared  the  PDSS  Concept  Plan  for  BAS  developed  a  generalized  software 
support  model  for  PDSS.  This  model,  which  illustrates  the  general  roles  of 
both  the  CD  and  MD  in  the  PDSS  process  and  their  relationships  with  system 
Users,  is  illustrated  in  this  report  as  Figure  2-1.  This  model  combines 
aspects  of  organizational  structure,  physical  location,  and  information  flow. 
The  model  was  designed  to  provide  for  a  systematic  flow  of  post-deployment 
software  problems  and  solutions  between  the  User  and  appropriate  CD  and  MD 
organizations.  As  indicated,  the  focal  point  for  MD  PDSS  activity  is  the  PDSS 
center.  The  PDSS  Concept  Plan  for  BAS  provides  for  establishing  11  of  these 
centers  as  discussed  in  Chapter  1.  As  shown  in  Figure  2-1,  the  CD  counterpart 
to,  and  principal  point  of  interface  with,  the  MD-managed  PDSS  center  is  to  be 
the  Combat  Development  Support  Facility  (CDSF).  The  CDSF,  which  represents 
the  focal  point  for  CD  PDSS  activity,  is  to  operate  in  response  to  requirements 
of  the  Combat  Development  System  Manager  (CDSM)  who  has  CD  PDSS  responsibility 
for  the  system  or  systems  being  addressed.  The  CDSM,  in  turn,  represents  the 
CD  in  interactions  with  the  Materiel  Manager  under  whose  supervision  the  PDSS 
center  functions.  It  should  be  noted  that  the  CDSF  should  be  construed  more 

as  a  physical  facility  than  an  organizational  entity.  Like  a  command  post,  the 
CDSF  is  essentially  a  place  where  equipment  and  personnel  from  various  organ¬ 
izational  entities  are  collocated  and  structured  to  most  effectively  perform 
certain  PDSS  functions,  when  or  as  required.  The  CDSF,  with  respect  to  both 
the  physical  facility  itself  and  the  staff  entities  located  within  it,  may  be 
either  permanent  or  temporary. 

(2)  Generalized  Combat  Developer  PDSS  Models.  Considering  the 
structure  and  procedural  concept  of  the  Generalized  Support  Model  for  PDSS,  and 
the  TRADOC  PDSS  system  design  guidelines  discussed  in  Paragraph  2-2,  the  Study 
Team  developed  two  models  for  the  functional  and  management  structure  of  the 
CDSF.  Two  generalized  models  (representing  opposite  points  on  a  spectrum)  were 
needed  to  accommodate  the  differences  in  current  organizational  structure,  cap¬ 
abilities,  and  requirements  among  TRADOC  centers  and  schools  as  discussed  in 
Paragraph  2-2. b. (4),  above.  The  overall  TRADOC  Objective  PDSS  System  design  is 
based  on  one  or  the  other  or  some  intermediate  variation  of  these  generalized 
models  being  implemented  at  each  center  and  school  that  has  a  need  for  a  PDSS 
capability.  The  two  models  are  described  below: 


y 
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GENERALIZED  SOFTWARE  SUPPORT  MODEL  FOR  PDSS 


c* 


*  Based  on  illustration  in  the  PDSS  Concept  Plan  for 
BAS,  May  1980. 


Figure  2-1.  Generalized  Software  Support  Model  for  PDSS 
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(a)  CO  POSS  Generalized  Model  1.  This  model,  which  is  illustr¬ 
ated  in  Figure  2-2,  is  based  on  the  existence/establishment  of  a  permanent  or¬ 
ganizational  entity  dedicated  to  PDSS  functions  and  staffed  by  an  element  of  the 
Directorate  of  Combat  Developments  (or  the  Management  Information  Systems 
Directorate  in  cases  where  this  organization  is  responsible  for  systems 
development  and  life  cycle  management  functions.)  This  PDSS  entity  is  taken, 

in  this  model,  to  be  located,  together  with  personnel  and  equipment,  in  a 
permanent  facility  identified  as  a  CDSF.  Other  directorates  and  staff  organ¬ 
izations  of  the  center  and  school  would  support  PDSS  functions  within  their 
respective  functional  areas  of  responsibility,  on  an  as  required  basis.  The 
figure  shows  those  elements  constituting  the  permanent  staffing  of  the  CDSF 
as  well  as  the  principal  organizational  elements  participating  in  PDSS 
functions  on  an  as  required  basis.  The  permanent  CDSF  staff  element(s) 
function  under  the  staff  supervision  of  the  Director  of  Combat  Developments 
or  a  designated  division  or  separate  office  chief  of  this  directorate.  Close 
staff  coordination  is  maintained  with  the  appropriate  CDSM  and  TRADOC  System 
Manager  (TSM),  if  a  TSM  exists,  and  with  other  staff  elements  supporting  PDSS 
functions.  The  CDSM  and  the  chief  of  the  permanent  CDSF  element  provide  the 
principal  interfaces  with  associated  Materiel  Developer  counterparts  as 
illustrated  in  Figure  2-2.  These  are  the  same  principal  interfaces  as  shown 
in  the  Generalized  Software  Support  Model  in  Figure  2-1.  As  indicated  in 
Appendix  C,  PDSS  for  the  several  BAS  which  any  given  TRADOC  center  and  school 
is  proponent  may  be  provided  by  more  than  one  MD-managed  PDSS  center.  This 
creates  the  functional  requirement  for  the  proponent  TRADOC  center  and  school 
to  maintain  an  interface  with  each  of  these  supporting  PDSS  centers,  all  but 
one  of  which  will  be  located  at  geographical  location(s)  separate  from  the 
center  and  school.  The  way  in  which  the  required  liaison/interaction  is 
accomplished  (e.g.,  whether  by  TDY  or  permanent  liaison  representation)  is 
the  prerogative  of  the  proponent  center  and  school.  Arrangements  for 
effecting  the  needed  1 iaison/interaction  will  be  developed  in  conjunction 
with  the  MD  organization(s)  concerned. 

(b)  CD  PDSS  Generalized  Model  2.  This  model,  which  is  illustr¬ 
ated  in  Figure  2-3,  differs  from  Model  1  in  that,  with  the  exception  of  a  de¬ 
signated  PDSS  focal  point,  no  distinct  PDSS  organizational  entity  exists  on  a 
permanent  basis,  and  there  is  no  permanent  CDSF.  Model  2  is  based  on  the  con¬ 
cept  of  PDSS  functions  being  performed  by  existing  organizational  elements 
(augmented  as  necessary  consistent  with  the  additional  workload  resulting  from 
PDSS).  This  model  allows  for  the  establishment  of  a  CDSF  on  an  ad  hoc  basis 

as  required,  with  staffing  being  drawn  temporarily  from  the  Directorate  of 
Combat  Developments  (or  Management  Information  Systems  Directorate)  and  other 
existing  organizational  elements  that  have  PDSS  responsibilities.  When  such 
a  CDSF  is  formed,  internal  CD  staff  supervision  and  coordination,  and  CD-MD 
interface  procedures  and  responsibilities  envisioned  under  Model  2  are 
essentially  the  same  as  described  for  Model  1. 
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2-3.  SYSTEM  OVERVIEW.  Following  the  assumptions,  design  guidelines,  generalized 
model  alternatives,  and  other  considerations  discussed  in  Paragraph  2-2,  the 
Study  Team  designed  and  developed  the  description  of  the  TRADOC  Objective  PDSS 
System  presented  in  this  report.  This  system  is  illustrated  in  Figure  2-4, 
structured  within  the  context  of  the  BFA  concept.  This  structure  is  in  con¬ 
sonance  with  the  Hybrid  Approach  for  establishing  MD-managed  PDSS  centers,  dis¬ 
cussed  in  Chapter  1  and  documented  in  the  PDSS  Concept  Plan  for  BAS,  May  1980. 

As  shown,  this  Objective  System  provides  for: 

•  A  PDSS  Staff  Element  at  Headquarters,  TRADOC  to  provide  a  focal 
point  for  PDSS  administration  and  policy  at  the  major  command 
level  and,  in  conjunction  with  the  HQ  TRADOC  CD  "hardware 
directorates,"  to  coordinate  and  exercise  staff  supervision  over 
PDSS  matters  within  TRADOC 

•  PDSS  Staff  Elements  at  CACDA  to  provide  a  capability  to  fulfill 
assigned  responsibilities  as  the  TRADOC  PDSS  proponent  and 
principal  integrating  center  and  as  proponent  of  the  CCS^  concept. 

The  CDSM  and  the  Chief  of  the  permanent  CDSF  Staff  Element  provide  the 
principal  interfaces  with  associated  Materiel  Developer  counterparts  as 
illustrated  ir,  Figure  2-2.  These  are  the  same  principal  interfaces  as  shown 
in  the  Generalized  Software  Support  Model  in  Figure  2-1. 

•  A  P^SS  capability  at  the  seven  major  TRADOC  doctrinal  centers 
that  have  proponency  for  functional  area  components  of  the  BFA 
concept 

•  CDSM  representation  for  each  BAS  that  has  reached  Milestone  II  in 
the  system  development  cycle  (or  a  comparable  point  for  systems 
being  developed  under  other  (e.g.,  evolutionary)  concepts)  (A  CDSM 
may  be  responsible  for  more  than  one  BAS  within  a  given  BFA.) 

•  Provisions  for  maintaining  contact  with  those  geographically 
separated  MD  PDSS  Centers  with  which  the  CD  must  interact 
regularly  in  planning  and  providing  PDSS  for  BAS  for  which  the  MD 
and  CD  each  have  major  responsibilities  in  their  respective 
functional  areas. 

It  is  emphasized  that  the  composition  of  this  total  system  as  well  as  each  of 
its  elements  has  been  tailored  to  satisfy  TRADOC's  functional  PDSS  requirements. 
Each  component  and  subordinate  element  of  the  system  is  discussed  in  detail  in 
Paragraph  2-5. 

2-4.  CONCEPT  OF  OPERATIONS.  The  concept  of  operations  associated  with  this 
Objective  PDSS  System  is  in  full  accordance  with  current  Department  of  the 
Army  and  TRADOC  operating  policies  and  procedures.  Principal  elements  of 
this  concept  are  discussed  below. 
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a.  HQ  TRADOC.  The  Commanding  General,  TRADOC,  through  the  Deputy  Chief 
of  Staff  for  Combat  Developments  (DCSCD),  establishes  operating  policy,  deter¬ 
mines  priorities,  allocates  and  manages  resources,  and  directs  all  elements  of 
this  Objective  PDSS  System  in  the  accomplishment  of  the  overall  mission  and 
principal  functional  responsibilities.  Within  DCSCD,  the  Telecommunications, 
Command  and  Control,  and  Computer  Systems  (TC4S)  Directorate,  the  Systems 
Management  Directorate,  and  each  of  the  "hardware  directorates",  e.g., 

Firepower  Systems,  Maneuver  Systems,  etc.,  have  PDSS  responsibilities. 

(1)  DCSCD  TC4S  Directorate.  The  Director,  TC4S,  exercises  staff 
supervision  over  the  operation  of  each  major  element  of  the  system.  Within 
this  Directorate,  the  Battlefield  Systems  Integration  Branch  provides  the 
focal  point  for  coordinating  all  TRADOC  PDSS  activity  and  requirements.  PDSS 
Action  Officers  of  this  branch  form  the  Headquarters  TRADOC  PDSS  Staff  Element. 
These  action  officers  are  responsible  for  receiving  and  acting  or  coordinating 
action  on  directions  or  requirements  from  Headquarters,  Department  of  the  Army 
(HQDA),  or  the  Commanding  General  and  other  appropriate  officials  of 
Headquarters,  TRADOC,  and  on  requests  from  User  commands.  In  conjunction  with 
action  officers  in  the  DCSCD  hardware  directorate(s)  and  the  CACDA  PDSS  Staff 
Element  (discussed  below),  they  analyze  and  translate  these  into  requirements 
or  instructions  for  issuance  by  Headquarters  TRADOC  to  subordinate  commands. 
Subsequently,  they  exercise  staff  supervision  and  act  in  coordination  with 
other  staff  elements  of  DCSCD  on  the  products  of  subordinate  elements  of  the 
system.  These  action  officers  also  serve  as  the  coordination  point  for  PDSS 
administration  and  policy  matters  within  TRADOC  and  provide  a  principal  interface 
on  these  PDSS  matters  with  HQDA  and  organizations  at  the  major  command  level 
external  to  TRADOC. 

(2)  DCSCD  Hardware  Directorates .  The  DCSCD  hardware  directorates 
exercise  staff  supervision  for  total  systems  management  of  systems  within 
their  respective  functional  areas. 

(3)  DCSCD  Systems  Management  Directorate.  The  Systems  Manage¬ 
ment  Directorate  exercises  primary  staff  responsibility  for  management 

of  the  TRADOC  Materiel  Total  System  Management  Concept  and  the  TSM  Program. 

b.  CACDA.  CACDA  is  responsible  and  will  operate  in  this  objective 
system,  as  the  TRADOC  PDSS  Proponent.  Responsibilities  associated  with  this 
role  include  working,  in  conjunction  with  the  PDSS  staff  at  Headquarters  TRADOC, 
to  address  major  PDSS  functional  and  management  matters,  and  coordinating  and 
integrating,  as  appropriate,  PDSS  requirements  and  activity  of  the  TRADOC 
centers  and  schools.  To  fulfill  these  responsibilities,  this  Objective  System 
provides  for  the  augmentation  of  the  OINTACCS  Office,  Army  C^/JINTACCS  Division, 
C3I  Directorate  with  staff  officers  dedicated  to  PDSS  requirements. 

c.  BFA-Level  Operations.  As  noted  in  the  System  Overview,  this  Objec¬ 
tive  System  provides  for  a  PDSS  capability  within  each  of  the  seven  functional 
areas  recognized  in  the  BFA  concept.  This  PDSS  capability  is  established  and 
will  operate  as  an  integral  part  of  the  combat  developments  or  management  in¬ 
formation  systems  organization  of  each  parent  center  and  school.  This  PDSS 
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capability  provides  a  focal  point  for  all  substantive  PDSS  activity  within 
each  of  the  seven  functional  areas  of  the  BFA  concept  and  provides  the  primary 
interface  on  PDSS  matters  at  the  BFA  level  with  organizations  external  to 
TRADOC.  Each  of  the  centers  and  schools  that  is  to  have  a  PDSS  capability 
will  be  responsible  for  planning,  directing,  coordinating,  and  performing  all 
CD  PDSS  functions  for  the  BAS  within  their  respective  functional  areas.  This 
includes  maintaining  contact  with  Systems  Users  on  functional/operational 
matters  and  with  MD  PDSS  centers  on  all  aspects  of  PDSS  for  the  BAS  with  which 
they  are  concerned.  The  CD  PDSS  LNOs  included  in  this  Objective  System  are 
extensions  of  their  respective  center  and  school  PDSS  organization.  They 
facilitate  CD-MD  interaction  on  PDSS  for  the  BAS  with  which  they  are  concerned 
and  provide  the  principal  User  Representation  at  the  MD  PDSS  center  where  they 
are  located. 

d.  Principal  Interfaces.  To  properly  fulfill  its  CD  PDSS  functions, 

HQ  TRADOC  and  each  center  and  school  involved  with  the  Objective  PDSS  System, 
must  interact  with  both  Users  and  Materiel /System  Developers  on  a  continuing 
basis.  The  CD  PDSS  LNOs  to  be  established  as  part  of  this  Objective  PDSS 
System  will  facilitate  this  interface.  A  summary  of  the  principal  CD-MD-User 
interfaces  that  are  seen  to  be  required  following  implementation  of  the 
PDSS  Concept  Plan  for  BAS,  are  shown  in  Figure  2-5. 

2-5.  OBJECTIVE  PDSS  SYSTEM  COMPONENTS. 

a.  General .  This  paragraph  contains  a  description  of  each  of  the  com¬ 
ponents  of  the  Objective  PDSS  System,  shown  in  Figure  2-4.  For  each  BFA- 
level  component  these  descriptions  include  a  general  discussion  of  the  BFA 
and  the  nature  of  PDSS  requirements  within  the  BFA,  a  discussion  of  the 
current  system  for  handling  these  PDSS  requirements,  and  a  description  of 
that  portion  of  the  proposed  TRADOC  Objective  PDSS  System  designed  to 
provide  an  improved  capability  to  fulfill  PDSS  responsibilities  in  each 

BFA.  These  descriptions  of  the  various  BFA  system  components  are  intended 
to  serve  as  a  framework  and  guide  to  permit  and  enable  each  affected  center 
and  school  to  proceed  with  detailed  PDSS  implementation  planning.  These 
proposed  system  component  designs  reflect  CD  PDSS  requirements,  policies,  and 
procedures  as  known  at  present.  These  and  other  factors  that  influence  system 
design  are  of  course  subject  to  change  any  time.  Therefore,  within  the  con¬ 
straints  and  guidelines  discussed  in  Paragraphs  2-2  through  2-4,  each  affected 
center  and  school  should  have  authority  to  modify  the  design  of  its  respective 
Objective  PDSS  System  component,  consistent  with  changes  in  PDSS  requirements 
and  other  related  influencing  factors. 

b.  Headquarters,  TRADOC. 

(1)  Role.  The  role  and  responsibilities  of  HQ  TRADOC  in  this 
Objective  PDSS  System  are  seen  to  be  essentially  the  same  as  at  present. 

This  role  is  basically  one  of  establishing  policy,  assigning  responsibility, 
allocating  resources,  and  exercising  command,  control,  and  staff  supervision 
over  the  total  system  operation.  CACDA  works  closely  with  and  supports  HQ 
TRADOC  in  this  role  by  serving  as  the  TRADOC  PDSS  proponent.  This  CACDA 
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Figure 2-5.  Principal  CD-MD-User  PDSS  interfaces 
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role  is  discussed  in  Paragraph  c,  below.  Most  POSS  requirements  and  oper¬ 
ations  are  assigned  to  BFA-level  components  of  this  Objective  System  for 
planning,  programming,  and  execution. 

(2)  Organization  and  responsibilities.  As  discussed  previously, 

POSS  is  accomplished  within  TRADOC,  as  a  part  of  the  combat  developments  mis¬ 
sion  directed  by  the  Deputy  Chief  of  Staff  for  Combat  Developments  (DCSCD). 
Organizational  staff  elements  principally  involved  with  this  effort  are  shown 
in  Figure  2-  6.  This  Objective  PDSS  System  is  based  on  continuation  of  this 
overall  operating  concept.  Within  DCSCD,  the  Battlefield  Systems  Integration 
Branch  of  the  Telecommunications,  Command  and  Control,  and  Computer  Systems 
(TC4S)  Directorate  serves  as  the  focal  point  for  PDSS  activity  at  HQ  TRADOC 
with  responsibility  for  coordinating  the  associated  PDSS  activity  of  other 
staff  elements.  Each  of  the  “hardware  directorates"  (e.g..  Firepower  Systems, 
Maneuver  Systems,  etc.)  in  DCSCD  has  staff  responsibility  for  coordinating 
PDSS  activity  with  its  associated  functional  center.  Within  these  DCSCD 
directorates,  designated  staff  officers  exercise  this  responsibility  for  one 
or  more  systems  in  their  functional  areas.  Other  directorates  of  DCSCD  and 
elements  of  other  major  TRADOC  staff  elements  outside  of  DCSCD  participate  in 
a  coordination  role  on  PDSS  staff  actions  impacting  their  areas  of  functional 
responsibility. 

(3)  Capabilities.  Although  the  Battlefield  Systems  Integration 
Branch  has  been  assigned  primary  HQ  TRADOC  staff  responsibility  for  PDSS,  no 
personnel  resources  have  been  committed  to  this  function  on  a  full-time  or 
dedicated  basis.  Current  staffing  of  this  branch  is  not  adequate  to  support 
such  a  commitment.  To  properly  fulfill  current  responsibilities  and  handle 
the  projected  increase  in  PDSS  requirements  as  more  systems  are  fielded  through 
the  program  years,  additional  personnel  are  needed  within  the  Battlefield 
Systems  Integration  Branch.  To  provide  the  capability  needed,  this  Objective 
PDSS  System  concept  provides  for  the  establishment  of  a  PDSS  Staff  Element 
within  the  Systems  Integration  Branch.  This  element  would  provide  the  focal 
point  for  coordination  of  all  TRADOC  PDSS  administration  and  policy  matters, 
and  the  means  through  which  HQ  TRADOC  staff  supervision  can  be  exercised  over 
this  important  functional  area.  The  relationships  that  exist  and  operating 
procedures  that  have  been  established  between  the  hardware  directorates  of 
DCSCD  and  their  associated  center(s)  and  schools(s)  would  remain  the  same 
following  implementation  of  this  Objective  PDSS  System. 

(4)  Resource  requirements.  Based  on  evaluation  of  the  currently 
known  workload,  it  is  estimated  that  four  additional  staff  officers  are 
needed  in  the  Systems  Integration  Branch  to  implement  this  Objective  PDSS 
System.  One  of  these  personnel  is  needed  in  FY  81  and  one  each  in  FY  82, 

84,  and  86  as  shown  in  Figure  2-7.  It  is  proposed  that  two  of  these  staff 
members  be  military  officers  with  combat  arms  backgrounds  and  secondary 
specialties  in  operations  research/systems  analysis  or  automatic  data  pro¬ 
cessing.  The  other  members  should  be  civilians  in  the  operations  research/ 
systems  analysis  or  automatic  data  processing  career  fields.  This  will  pro¬ 
vide  a  desirable  blend  of  functional  and  technical  knowledge  and  expertise 
and  should  also  provide  a  means  of  maintaining  the  long  term  continuity 
needed  in  this  functional  area.  Estimated  costs  of  these  personnel  are  shown 
in  Figure  2-8. 
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Figure  2-6.  HQ  TRADOC  staff  elements  with  major 
responsibilities  in  the  PDSS  System 
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Figure  2-7.  Personnel  requirements,  HQ  TRADOC 


HQ  TRADOC,  ESTIMATED  PERSONNEL  COSTS  ($000)* 


Civilian 

Personnel 

Fiscal  Year 

81  82  83  84  85  86  87 

0  31.6  31.6  63.2  63.2  63.2  63.2 

*  In  FY  81  constant  dollars.  Based  on  average  annual  costs  of  $31. 6K, 
including  10  percent  loading,  for  one  technical  civilian. 
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c.  Combined  Arms  Combat  Development  Activity  (CACDA). 

(1)  General .  This  paragraph  contains  a  discussion  of  CACDA's  PDSS 
roles  in  four  distinct  functional  areas  —  as  proponent  for  the  CCS^  concept, 
as  the  TRADOC  PDSS  proponent,  as  proponent  for  the  Force  Level  Control  Func¬ 
tional  Area,  and  as  proponent  for  the  Maneuver  Battlefield  Functional  Area. 

While  functional  responsibilities  for  each  of  these  areas  are  currently  as¬ 
signed  to  existing  organizational  elements  of  CACDA,  an  improved  capability 
is  needed  to  meet  the  growing  requirements  associated  with  PDSS  as  the  number 
and  complexity  of  deployed  BAS  continue  to  increase.  Also,  the  requirement 
to  closely  coordinate  and  integrate  activities  involved  with  the  development 
and  support  of  command  and  control  BAS  under  the  CCS^  concept  imposes  an 
additional  workload  on  the  responsible  elements  of  CACDA.  The  Objective  PDSS 
System  is  designed  to  provide  the  improved  capability  needed  to  meet  these 
requirements  while  minimizing  changes  to  the  current  organizational  structure 
and  functional  responsibilities. 

(2)  The  current  system. 

2  2 

(a)  CCS  proponency.  CACDA  is  proponent  for  the  CCS  concept 

which  addresses  the  application  of  automation  and  communications  to  the  battle¬ 
field  decision  making  process.  At  present,  actions  associated  with  this  con¬ 
cept  are  directed  toward  the  further  development  and  refinement  of  the  CCS^ 
architecture  with  the  ultimate  objective  of  achieving  an  integrated  battlefield 
command  and  control  network.  This  effort  requires  coordination  and  integration 
of  the  design  and  development  of  Force  Control  and  Maneuver  Control  systems 
with  other  functional  area  control  systems,  and  these  control  systems  with  their 
subordinate  systems,  to  ensure  that  the  necessary  degree  of  interoperability 
will  be  achieved  among  these  battlefield  automated  systems.  As  the  development 
of  these  systems  proceeds  and  the  number  that  are  deployed  increases,  a  greater 
proportion  of  CCS^  concept-related  actions  will  be  focused  on  ensuring  that 
required  interoperability  is  maintained  as  systems  are  modified  through  PDSS 
actions.  The  magnitude  and  complexity  of  this  effort  will  continue  to  grow 
as  more  systems  are  fielded,  modified,  and  eventually  phased  out  and  replaced 
by  new  systems.  This  total  effort  will  require  continuing  coordination  between 
and  among  CACDA  and  each  center  and  school  that  is  proponent  for  one  or  more 
control  systems  or  other  BAS  which  have  inter-BFA  interoperability  requirements. 
The  focal  point  for  CCS^  proponency  in  CACDA  is  the  Army  C^/JINTACCS  Division 
of  the  Command,  Control,  Communications,  and  Intelligence  (C3I)  Directorate. 

(b)  TRADOC  PDSS  proponency.  Within  CACDA-  the  focal  point  for 
exercising  PDSS  proponency  is  the  JINTACCS  Office,  Army  CVJINTACCS  Division, 

C3I  Directorate.  In  this  role,  functions  performed  involve  monitoring,  coordi¬ 
nating,  and  integrating  as  appropriate,  the  PDSS  requirements  of  TRADOC  Centers 
and  Schools,  and  interacting  with  Materiel/System  Developers  (e.g.,  DARCOM, 
USACSC,  INSCOM,  and  USACC)  on  PDSS  plans  and  policy  matters.  Included  in  this 
role  is  the  responsibility  to  monitor  the  overall  operation  of  the  PDSS  system 
throughout  TRADOC  and  initiate  or  recommend  to  HQ  TRADOC,  actions  to 

correct  deficiencies  or  otherwise  improve  the  capabilities  of  the  system  as 
needed.  These  functions  are  performed  in  close  concert  with  the  Systems 
Integration  Branch,  TC4S  Directorate,  DCSCD,  HQ  TRADOC. 
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(c)  Force  Level  Control  Functional  Area  proponenc 


1_.  Functional  responsibilities.  TRADOC  Reg.  10-41  assigns 
the  Combined  Arms  Combat  Development  Activity  (CACDA)  responsibility,  among 
other  things,  for  developing  doctrine,  organization,  and  materiel  require¬ 
ments  for  tactical  command  and  control  systems.  Within  CACDA,  this  respon¬ 
sibility  is  assigned  to  the  C3I  Directorate.  The  Army  C  /JINTACCS  Division 
of  this  directorate  serves  as  the  TRADOC  proponent  for  Force  Control  and 
Maneuver  Control  (FC  &  MC)  systems,  as  the  focal  point  for  integration  of 
ADR  concepts  and  doctrine  for  these  systems,  and  as  the  TRADOC  point  of 
contact  with  DARCOM  on  actions  involving  tnese  systems.  A  TRADOC  System 
Manager's  (TSM)  office  for  SIGMA,  the  principal  system  in  the  Force  Level 
Control  Functional  Area,  has  been  established  but  is  just  in  the  process  of 
being  staffed.  Prior  to  this  office  reaching  an  operational  status,  functions 
that  would  normally  be  performed  by  a  TSM  for  this  system  were  accomplished 
by  the  Army  C  /JINTACCS  Division. 

2_.  BAS  to  be  supported.  The  BAS  to  be  supported  in  this 
functional  area  are  shown  in  Figure  2-9.  While  the  Position  Location  Re¬ 
porting  System  (PLRS)  is  included  functionally  in  this  area,  it  will  be 
addressed  in  further  detail  in  the  discussion  of  the  Communications  Func¬ 
tional  Area  since  the  US  Army  Signal  Center  (USASC)  is  the  proponent  and 
will  have  the  greatest  requirement  for  resources  to  provide  PDSS  for  this 
system.  As  indicated  in  Figure  2-9,  the  OCCIS  (Phase  I  SIGMA)  requires  PDSS 
at  present  as  a  result  of  a  current  effort  to  field  and  test  an  evolutionary 
developmental  operations  control  and  command  information  system  in  USAREUR 
under  operational  conditions. 

(d)  Maneuver  BFA  propvnency. 

1_.  Functional  responsibilities.  The  US  Army  Combined 
Arms  Center  is  designated  by  TRADOC  Reg.  10-41  as  one  of  three  major  TRADOC 
integrating  centers.  It  has  the  mission  of  integrating  and  coordinating 
materiel  and  force  modernization  requirements  within  the  combined  arms  func¬ 
tional  areas  of  combat,  combat  support,  and  command  and  control.  Included 
in  this  mission  is  TRADOC  proponency  for  the  Maneuver  BFA.  Within  the  Com¬ 
bined  Arms  Center  (CAC),  CACDA  has  primary  responsibility  for  this  mission 
and  serves  as  the  TRADOC  proponent  and  integrator  of  combat  developments  in 
the  Maneuver  BFA.  CACDA  and  the  other  Maneuver-BFA-associated  TRADOC  centers 
and  schools  are  shown  in  Figure  2-10.  Of  the  associated  centers  and  schools 
shown  in  the  figure,  only  the  US  Army  Armor  Center  and  the  US  Army  Aviation 
Center  are  currently  proponents  for  BAS  being  addressed  in  this  study.  TRADOC 
System  Managers  (TSM)  involved  with  BAS  in  this  BFA  include: 

•  The  TSM,  Advanced  Attack  Helicopter  (AAH),  located  at  the  Aviation 
Center  but  responsible  to  the  Armor  Center,  the  system  proponent 

•  The  TSM,  XM-1  Tank,  located  at  the  Armor  Center.  The  fire  control 
system  of  the  XM-1  Tank  is  a  Category  3  BAS.  The  Combined  Arms 
Center  is  the  proponent  for  this  BAS 
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•  TSM,  Position/Navigation,  located  at  CACDA,  who  has  responsibility 
for  the  AN/PSN-6  Position  Location  Navigation  Set  (LORAN),  a  Cate¬ 
gory  3  system  in  this  BFA,  as  well  as  responsibility  for  additional 
BAS  addressed  in  other  BFA,  e.g.,  PLRS,  GPS. 

Also  shown  in  Figure  2-10  are  the  subordinate  elements  of  CACDA  that  are  in¬ 
volved  in  the  development  and  life  cycle  management  of  BAS  in  this  BFA.  As 
indicated  by  the  figure,  functions  associated  with  Maneuver  BFA  BAS  fall  into 
three  directorates  within  CACDA.  Responsibilities  of  each  of  these  organiz¬ 
ations  are  discussed  in  the  paragraphs  that  follow. 

a_.  Concepts  and  Doctrinal  Management  Directorate. 

This  directorate,  among  other  functions,  acts  as  the  CAC  point  of  contact  for 
the  maneuver  system  at  corps,  division,  and  brigade  levels.  This  function  is 
further  assigned  to  the  Combined  Arms  Concepts  Division  of  this  directorate. 

b^.  Materiel  Integration  Directorate.  This  director¬ 
ate  is  responsible  for  reviewing,  integrating,  and  validating  all  materiel 
requirements  documents  developed  by  TRADOC-associated  schools/centers.  The 
Combat  Division  of  this  directorate  serves  as  the  CAC  proponent  for  materiel 
combat  developments  pertaining  to  armor,  infantry,  aviation,  airborne,  and 
special  forces,  major  components  of  the  Maneuver  BFA. 

c.  C3I  Directorate.  This  directorate  serves  as  the 
TRADOC  proponent  for  the  Command  Control  System,  for  Battlefield  Automated 
Systems  (BAS)  Management,  and  the  Force  Level  and  Maneuver  Control  System. 
Within  this  directorate,  the  Army  CVJINTACCS  Division  serves  as  the  TRADOC 
proponent  for  Force  Control  and  Maneuver  Control  (FC  &  MC)  systems,  and  acts 
as  the  TRADOC  focal  point  for  PDSS.  The  Methodology  and  Analysis  Division  is 
the  TRADOC  proponent  for  BAS  management  and  for  coordinating,  assessing  and 
integrating  the  tactical  data  and  related  communications  system  requirements 
of  combat,  combat  support,  and  combat  service  support  organizations. 

2_.  BAS  to  be  Supported.  The  Advanced  Attack  Helicopter 
is  the  only  Category  1  or  2  BAS  to  be  addressed  in  this  BFA  at  this  time.  As 
mentioned  previously,  the  US  Army  Armor  Center  is  the  proponent  for  this  sys¬ 
tem.  In  addition  to  this  Category  2  BAS,  there  are  13  Category  3  BAS  in  this 
BFA  which  will  also  require  some  Combat  Developer  participation  in  the  PDSS 
effort  devoted  to  them.  The  US  Army  Aviation  Center  is  the  proponent  for  10 
of  these  systems,  CAC  is  the  proponent  for  three.  It  should  also  be  noted 
that  portions  of  both  SIGMA  and  PLRS  are  to  support  this  BFA.  However,  PDSS 
for  these  systems  is  addressed  under  the  discussion  of  the  Force  Level  Control 
and  the  Communications  Functional  Areas,  respectively,  since  it  is  in  those 
areas  that  the  greatest  requirement  for  PDSS  resources  to  support  these  systems 
will  exist. 
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(3)  The  Objective  System. 

(a)  Purpose  and  scope.  The  Objective  PDSS  System  component 
described  in  this  paragraph  has  been  designed  to: 

•  Provide  an  improved  capability  to  handle  PDSS-related  matters 
associated  with  the  CCS^  concept 

•  Provide  CACDA  an  improved  capability  to  fulfill  its  responsibilities 
as  the  TRADOC  POSS  proponent,  consistent  with  the  expanding  role  of 
the  Combat  Developer  in  this  functional  area 

•  Provide  organizations  involved  with  BAS  in  the  Force  Level  Control 
Functional  Area  and  the  Maneuver  BFA,  an  adequate  capability  to 
accomplish  those  CD  PDSS  functions  for  which  they  are  responsible. 

(b)  Principal  features  and  structure.  This  Objective  PDSS 
System  component  can  be  generally  characterized  as  an  enhancement  of  current 
PDSS  capabilities  through  the  augmentation  and  expansion  of  CACDA's  existing 
organizational  structure  rather  than  establishing  new  PDSS  organizational 
elements.  It  does  not  provide  for  the  establishment  of  a  CDSF,  per  se,  for 
either  the  Force  Level  Control  Functional  Area  or  the  Maneuver  BFA,  but  does 
identify  focal  points  and  clearly  establishes  responsibilities  for  each  CD 
PDSS  function  that  must  be  performed.  It  provides  for  retention  of  current 
responsibilities  for  CCS^  and  TRADOC  PDSS  proponency  in  the  Army  CVJINTACCS 
Division  of  the  C3I  Directorate.  It  also  provides  for  establishing  the  focal 
point  for  planning,  conducting,  and/or  coordinating  CD  PDSS  activity  assoc¬ 
iated  with  BAS  in  both  the  Force  Level  Control  Functional  Area  and  the 
Maneuver  BFA  in  this  Division.  Support  in  the  areas  of  systems  requirements 
analysis  and  training  development/battlefield  simulations  development  would 
be  provided  by/arranged  through  the  Methodology  and  Analysis  Division  of  the 
C3I  Directorate  and  elements  of  the  Combined  Arms  Training  Development  Activity, 
respectively. 


(c)  Structure.  CACDA  organizational  elements  with  major  re¬ 
sponsibilities  in  this  component  of  the  TRADOC  Objective  PDSS  System  are  the 
same  as  those  shown  in  Figure  2-10.  A  more  detailed  illustration  of  the 
structure  of  the  Army  C  /JINTACCS  Division,  as  envisioned  under  the  concept 
of  this  Objective  PDSS  System,  is  provided  in  Figure  2-11.  The  CD  PDSS 
responsibilities  and  related  functions  of  each  element  of  this  division  are 
discussed  in  the  following  paragraph. 

(d)  Functional  responsibilities. 

2 

1_.  CCS  concept  proponency.  This  Objective  PDSS  System 
recognizes  the  growing  significance  of  PDSS  to  the  furtherance  of  the  CCS£ 
concept.  The  System  provides  for  a  staff  officer  augmentation  to  the  Army 
CvJINTACCS  Divison,  specifically  for  the  purpose  of  coordinating  PDSS  actions 
and  related  activities  that  impact  the  CCS^  concept.  This  augmentation,  which 
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is  shown  in  Figure  2-11  as  the  Army  CCS  -PDSS  coordinator,  is  consistent 
with  the  anticipated  increase  in  the  magnitude  and  complexity  of  functional 
requirements  in  this  area  as  more  command  and  control  and  other  BAS  are 
fielded. 


2_.  TRADOC  PDSS  proponency.  Under  the  concept  of  this 
Objective  PDSS  System,  primary  responsibility  for  this  functional  area  remains 
with  the  JINTACCS  Branch,  Army  C^/JINTACCS  Division.  A  PDSS  Staff  Element 
would  be  established  within  the  JINTACCS  Branch  to  provide  an  improved  cap¬ 
ability,  consistent  with  the  increasing  functional  requirements  associated 
with  this  responsibility.  As  shown  in  Figure  2-11,  the  components  of  this 
PDSS  Staff  Element  include: 

•  PDSS  Coordination 

•  Inter-BFA  Plans,  Interoperability,  and  Configuration  Control 

•  Inter-BFA  Testing  Coordination 

•  Analytical  Resources  Coordination. 

This  PDSS  Staff  Element  would  serve  as  the  focal  point  for  overall  integra¬ 
tion  and  coordination  of  PDSS  activities  for  which  CACDA  is  the  TRADOC  pro¬ 
ponent  and  principal  integrating  center.  This  includes  system  PDSS  planning, 
inter-BFA  interoperability  requirements,  and  configuration  control  under  the 
CCS^  concept,  and  inter-BFA  testing  coordination.  Also  included  is  respon¬ 
sibility  for  supporting  associated  centers  and  schools  in  identifying  and 
coordinating  the  efficient  use  of  analytical  resources  that  could  contribute 
to  the  resolution  of  CD  PDSS  requirements. 

2-  Force  Level  Control  Functional  Area  Proponency.  The 
concept  associated  with  this  Objective  PDSS  System  does  not  change  the  current 
functional  responsibilities  for  this  area.  The  Army  C  /JINTACCS  Division 
continues  to  have  overall  responsibility.  The  C2  Development  Branch  of  this 
division  would  be  the  focal  point  for  CD  PDSS  activity  associated  with  this 
functional  area  generally  under  the  concept  associated  with  CD  Generalized 
PDSS  Model  2  illustrated  in  Figure  2-3.  This  responsibility  includes  direct 
and  continuous  CD  participation,  in  coordination  with  the  TSM,  in  the  evolu¬ 
tionary  development,  fielding,  support,  maintenance,  and  life  cycle  manage¬ 
ment  (including  PDSS)  of  SIGMA,  the  principal  Force  Control  and  Maneuver 
Control  System.  The  C2  Development  Branch  would  have  primary  responsibility 
for  interaction  with  the  CORDACOM-managed  PDSS  center  to  be  established  and 
operated  at  Fort  Leavenworth.  Responsibilities  of  this  center  include  PDSS 
for  SIGMA.  To  fulfill  its  responsibilities,  the  C2  Development  Branch  would 
have  elements  as  shown  in  Figure  2-11.  The  general  responsibilities  of  the 
CDSM,  FC  &  MC  System  and  each  branch  element  are  described  below.  Specific 
PDSS  functions  are  shown  in  Figure  2-12. 
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Assignment  of  functions.  Force  Control  and  Maneuver 
Control  Systems  (continued  on  next  page) 
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a_.  CDSM,  Force  Level  and  Maneuver  Control.  The  CDSM, 
Force  Level  and  Maneuver  Control ^System,  serves  as  the  CD  for  software  assoc¬ 
iated  with  the  SIGMA  System.  He'is  responsible  for  managing  and  coordinating 
or  performing  all  software-related  actions  within  the  CD  PDSS  role  for  SIGMA. 

He  is  the  principal  Field  User's  representative  and  the  primary  point  of 
contact  with  the  MD  on  PDSS  matters  affecting  this  system.  Specific  functions 
with  which  he  is  involved  in  either  a  management,  coordination,  or  performance 
role  are  shown  in  Figure  2-12. 

b.  Plans,  Interoperability,  and  Configuration 
Control  Team.  This  team  supports  the  CDSM,  Force  Level  and  Maneuver  Control 
Systems  in  all  actions  associated  with  planning  PDSS  support  for  FC  &  MC  BAS 
during  both  pre-  and  post-deployment  phases  of  the  system  life  cycle.  The 
actions  include  planning  for  support,  in  coordination  with  the  responsible 
MD,  during  contingencies  and  crisis/wartime.  The  team  is  also  responsible 
for  CD  PDSS  actions  associated  with  system  interoperability  and  configura¬ 
tion  management  to  include  participation  with  the  cognizant  TSM  and/or  CDSM 
in  providing  representation  on  appropriate  configuration/control  boards. 

The  team  coordinates  with  the  CDSM  in  authorizing  release  of  system  change 
packages  to  the  field. 


c^.  System  Requirements  and  Analysis  Team.  This 
team  is  responsible  for  all  actions  involving  identification,  analysis,  and 
development  of  system  functional  change  requirements  and,  in  coordination 
with  the  CDSM  FC  &  MC  Systems  and  the  cognizant  TSM,  stating  these  require¬ 
ments  to  the  MD.  The  source  of  these  requirements  may  be  any  system  User  or 
cognizant  CD  organization.  Analyses  conducted  by  the  team  in  examining 
matters  such  as  system  problems,  proposed  system  changes,  and  the  impact  of 
conceptual  changes  in  tactics  or  doctrine  on  systems  may  be  manual,  computer- 
assisted,  or  fully  automated  depending  on  the  nature  of  the  problem  being 
addressed  and  the  resources  available. 

d_.  Testing  and  Training  Requirements  Team.  As 
suggested  by  its  title,  responsibilities  of  this  team  fall  generally  into 
two  functional  areas.  With  respect  to  testing,  the  team  is  responsible  for 
planning,  coordinating,  and  monitoring  or  conducting,  all  assigned  CD  actions 
associated  with  testing  changes  to  FC  &  MC  BAS.  Accomplishment  of  these 
responsibilities  involves  working  closely  with  the  MD,  OTEA,  TCATA,  and/or 
other  designated  test  activities,  as  appropriate.  The  team  is  also  respon¬ 
sible  for  determining  the  training  impact  of  system  changes  and  coordinating 
with  the  appropriate  training  developments  organization(s)  to  initiate  all 
actions  necessary  to  satisfy  training  requirements. 

4.  Maneuver  BFA  proponency.  As  described  in  Paragraph 
c.(2)(c),  above,  CACDA  responsibilities  associated  with  proponency  for  the 
Maneuver  BFA  are  divided  among  three  separate  directorates.  Under  the  con¬ 
cept  of  this  Objective  PDSS  System,  each  of  these  directorates  would  continue 
to  have  an  interest  in  PDSS  for  BAS  in  the  Maneuver  BFA,  consistent  with  their 
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current  responsibilities.  To  ensure  an  integrated  effort,  the  Objective  PDSS 
System  provides  a  focal  point  for  coordination  of  PDSS-related  activities  for 
Maneuver  BFA  BAS  within  CACDA  as  well  as  with  the  associated  centers  and 
schools  that  have  proponency  for  specific  BAS.  This  focal  point  is  the  PDSS 
Coordination  Element  in  the  JINTACCS  Branch,  Army  CVJINTACCS  Division  of 
the  C3I  Directorate.  This  element  is  identified  in  Figure  2-11.  The  Objec¬ 
tive  PDSS  System  concept  provides  that  each  center  and  school,  with  propon¬ 
ency  for  one  or  more  BAS  in  the  Maneuver  BFA,  would  designate  a  current  BAS 
project  officer  as  the  CDSM  for  each  BAS.  These  CDSM(s)  would  provide  the 
point(s)  of  contact  with  which  the  CACDA  PDSS  Coordination  Element  would  inter¬ 
act  with  respect  to  PDSS  requirements  involving  specific  BAS. 

(e)  Resources. 


1_.  Personnel.  Time  phased  estimates  of  personnel  re¬ 
sources  needed  to  establish  this  component  of  the  Objective  PDSS  System  are 
shown  in  Figure  2-13.  A  proposed  breakout  of  these  personnel  requirements 
(based  on  FY  87  needs)  by  organizational  element  are  shown  in  Figure  2-14. 

2 

2.  Major  items  of  equipment.  The  Army  C  Development 
Branch  requires  interactive  access  to  a  computer  at  the  Data  Processing  Field 
Office  (DPFO),  Fort  Leavenworth,  or  elsewhere,  to  conduct  simulations  and 
support  tests  and  other  analyses  conducted  to  support  FC  &  MC  systems.  This 
computer  access  is  also  required  to  facilitate  interaction  with  other  TRADOC 
centers  which  support  one  or  more  control  systems  in  the  CCS^  concept. 
Specific  equipment  required  to  provide  this  access  and  the  capability  re¬ 
quired  must  be  determined  during  detailed  implementation  planning. 


,3.  Facilities.  Physical  facility  requirements  include 
office  space  for  assigned  personnel,  a  computer  terminal  area,  and  a 
simulation/test/analysis  area  that  would  accommodate  up  to  10  to  12  personnel 
working  simultaneously. 


4.  Funds.  An  estimate  of  funds  required  for 
personnel  requirements  identified  above  is  shown  in  Figure  2-15. 
needed  for  equipment  facilities  are  dependent  upon  development  of 
requirements  and  plans  addressing  these  areas  as  part  of  detailed 
tation  planning. 
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CACDA ,  ESTIMATED  PERSONNEL  REQUIREMENTS 


PERSONNEL 

FY  81 

FY  82 

FY  83 

FY  84 

FY  85 

FY  86 

\ 

FY  87 

Required 

Military 

2 

4 

6 

7 

9 

11 

19 

Civil ian 

2 

3 

3 

5 

6 

6 

7 

TOTAL 

4 

7 

9 

12 

15 

17 

26 

Authorized 

Mi  1 itary 

1 

3 

4 

5 

7 

9 

14 

Civilian 

1 

1 

1 

2 

3 

3 

4 

TOTAL 

2 

4 

5 

7 

10 

12 

18 

Additional  Needed 

Military 

1 

1 

2 

2 

2 

2 

5 

Civilian 

1 

2 

2 

3 

3 

3 

3 

TOTAL 

2 

3 

4 

5 

5 

5 

8 

Figure  2-13.  Personnel  requirements,  CACDA 
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Figure  2-14.  Breakout  of  personnel  requirements,  CACDA 
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CACDA,  ESTIMATED  PERSONNEL  COSTS  ($000)* 

Fiscal  Year 


81 

82 

83 

84 

85 

86 

87 

Civilian 

Personnel 

63.2 

94.8 

94.8 

110.8 

142.4 

142.4 

168.4 

*  In  FY  81 

constant 

dollars. 

Based  on 

average 

annual  costs  of  $31 

.6  K, 

including  10  percent  loading,  for  one  technical  civilian  and  $16. OK 
for  one  administrative  level  civilian. 


Figure  2-15.  Estimated  personnel  costs,  CACDA 


d.  Communications. 


(1)  General .  The  Communications  functional  area  is  seen  to  extend 
over  and  into  all  of  the  other  BFA-level  components,  because  it  is  analogous 
to  the  central  nervous  system  of  the  whole  Army  body  of  BFA-level  components 
and  their  functions.  The  Communications  functional  area  must  effectively 
link  together  all  the  BFA-level  components  and  their  parts.  It  must 
"interoperate"  with  all  and  it  must  be  capable  of  handling  in  a  timely 
manner  all  of  the  essentia1  traffic  loads  that  are  necessary  for  the  various 
other  BFA-level  components  to  perform  their  functions  adequately  in  an 
intense  combat  environment.  If  the  Communications  functional  area  does  not 
do  its  job  adequately,  the  other  BFA-level  components  may  be  unable  to  do 
their  jobs  at  all . 

The  principal  systems  in  this  functional  area  range  from  the  Position 
Location  Reporting  System  (PLRS),  which  uses  time-of-arri val  technology  to 
spot  up  to  700  field  unit:;  through  the  more  versatile  PLRS/JTIDS  Hybrid, 
which  combines  position  determination  with  considerably  greater  communications 
capabilities,  in  secure  oigital  form;  automatic  central  office  telephone  and 
message  switching  systems;  satellite  communications  relay  systems;  both 
message  entry  and  output  recording  terminals;  and,  finally,  general  purpose 
automatic  test  equipment.  Electronics  and  electrical  engineering  technology 
is  heavily  reflected  in  these  systems,  and  essentially  all  of  the  newer 
systems  in  this  area  involve  a  substantial  degree  of  automation,  including 
embedded  software  and  computer  hardware.  PDSS  burdens  which  may  be  expected 
to  fall  upon  the  Signal  Center  are  clouded  by  the  fact  that  most  of  the 
significant  BAS  in  this  bFm  are  still  emerging  and  essentially  no  PDSS 
experience  exists  from  which  to  extrapolate. 

The  Signal  Center  must  be  prepared  to  face  the  issues  of  interoperability 
of  the  many  systems  tied  together  in  the  total  system.  The  general  trend 
toward  greater  automation  of  individual  battlefield  systems  is  presenting 
increasing  requirements  for  larger  volumes  of  traffic,  especially  digital 
traffic,  at  higher  data  rates  and  in  much  shorter  response  times.  In 
Artillery  and  Air  Defense  BAS,  seconds  are  critical,  as  opposed  to  the 
previously  prevailing  "real  time"  requirements  of  manual  command  and  control 
in  which  time  is  measured  in  minutes  to  hours.  These  trends  in  digital  data, 
time-compression,  traffic,  and  interoperability  requirements  dictate  a  need 
to  be  able  to  dynamically  simulate  and  analyze  the  total  system  since  they 
suggest  that  small  changes  in  connected  BAS  may  have  profound  effects  on  the 
total  system  that  are  not  predictable  with  the  largely  manual  methods  and 
tools  of  analysis  that  have  been  used  traditional ly.  Small  changes  may 
dynamically  impact  very  significantly  on  requirements  for  switching,  load 
capacities,  and  procedures  for  management  of  the  communication  network.  For 
analysis  purposes,  reliance  on  static  load  rates  alone,  from  a  source  such 
as  the  COMSR  data  base,  may  be  quite  misleading.  What  is  needed  is  a  cap¬ 
ability  to  simulate  dynamically  the  total  system,  under  a  variety  of  conditions, 
including  EW  and  EMP,  various  frequency  management  schemes  and  policies, 
structures,  and  loads,  and  see  what  happens.  This  capability  needs  to  be 
sensitive  to  variations  in  characteristics,  such  as  communication  protocols 
and  data  link  languages,  to  fully  explore  the  interoperability  aspects  among 
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BAS  and  other  systems  and  the  network  impact  of  changes  in  individual 
systems.  Issues  that  also  need  to  be  addressable  are  survivability,  and 
discrimination  among  types  of  information  being  handled,  so  that  time- 
critical  data  reaches  its  destination  soon  enough  and  accountability  is 
achieved  for  types  of  information  requiring  it.  Since  there  is  a  limit 
to  the  degree  of  detail  and  resolution  which  can  be  provided  in  any  single, 
total  network  simulation,  higher-resolution  simulations  of  parts  of  the 
network  or  separate  subsystems  will  also  be  required.  Such  a  capability, 
which  is  needed  to  come  to  grips  fully  with  the  fundamental  PDSS  issues, 
is  also  needed  to  perform  effectively  other  functions  in  combat  develop¬ 
ments,  training  developments  and  even  training  itself.  The  latter  is 
involved  particularly  because  of  the  significant  training  issues  related 
to  frequency  management,  network  management,  and  related  policy  implemen¬ 
tation  in  the  field. 

(2)  The  current  system.  The  focal  point  for  providing  PDSS  to 
the  BAS  within  the  Communications  Functional  Area  is  the  US  Army  Signal 
Center  and  Fort  Gordon  (USASC  &  FG).  The  organizational  structure  of  the 
baseline  system  within  USASC  &  FG  which  provides  this  PDSS  is  shown  in 
Figure  2-16.  As  shown  there,  the  TRADOC  action  level  elements  include 
personnel  from  three  directorates,  from  the  US  Army  Communications-Elect- 
ronics  Board,  and  from  five  TRADOC  System  Manager  (TSM)  Offices.  Figure  2-17 
shows  the  structure  of  the  total  TRADOC  Baseline  PDSS  System  for  the 
Communications  Functional  Area. 

(a)  Functional  responsibilities.  The  responsibilities  of 
the  organizational  elements,  shown  in  Figure  2-16,  are  many  and  varied.  In 
the  paragraphs  which  follow  only  those  responsibilities  which  are  related  to 
PDSS  for  BAS  within  the  Communications  Functional  Area  are  discussed. 

1_.  US  Army  Signal  Center  and  Fort  Gordon.  Included  in 
the  responsibilities  of  USASC  &  FG  are  the  following: 

t  Develops  and  validates,  through  coordination  with  the  User, 

communications-electronic  (C-E)  requirements  for  communications 
doctrine,  equipment  and  materiel 

•  Acts  as  the  US  Army  C-E  User  Representative  in  supporting  force 
development  objectives  and  activities  by  participating  with  the  US 
Army  combat  development  community,  on  studies,  analyses,  field 
experiments,  tests,  and  life  cycle  management  and  evaluation 

•  Participates  in  the  development  and  conduct  of  operational  test  and 
evaluations  for  C-E  doctrine,  communications  systems,  equipment  and 
materiel 

•  Evaluates  the  life  cycle  assessment  of  all  proponent  materiel  and 
training  systems  to  ensure  that  optimum  training,  doctrinal  and 
organizational  concepts  are  being  used. 
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US  ARMY  SIGNAL  CENTER  AND  FORT  GORDON 


Figure  2-16.  USASC  &  FG  elements  with  primary  responsibilities 
in  the  Baseline  PDSS  System 
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HQ,  US  ARMY  TRAINING  AND  DOCTRINE  COMMAND,  FORT  MONROE,  V A 


Figure  2-17.  Overall  TRADOC  elements  of  Baseline  PDSS  System 
for  the  Communications  Functional  Area 
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2.  Commanding  General,  USASC  &  FG.  The  Commanding 
General  has  the  following  responsibilities: 

•  Commands  all  elements  of  the  US  Army  Signal  Center,  Fort  Gordon 

•  Serves  as  the  Commandant  for  the  USASC  training  activities. 

2-  Concepts  and  Studies  Division  (C  &  S),  Directorate 
of  Combat  Developments,  USASC.  Among  this  organizational  element's  many 
functions,  those  which  may  impact  upon  PDSS  are  as  follows: 

•  Provides  input  to  general  functional  systems  requirements  and 
detailed  systems  requirements  for  automated  communications 
control  systems 

•  Assists  in  determining  requirements  and  preparing  proposals  for 
force  development  testing  and  experimentation  and  reviewing 
results 

•  Prepares,  coordinates,  and  reviews  international  standardization 
agreements  within  assigned  area  of  proponency 

•  Develops  maintenance  concepts  and  reviews  the  maintenance  test 
package 

•  Maintains  cognizance  of  computer  simulation  models  used  by  commun¬ 
ication  system  analyses  in  C-E  system  design,  engineering,  and 
evaluation. 

4.  Materiel  Systems  Development  Division,  Directorate 
of  Combat  Developments,  USASC.  This  organization's  PDSS  responsibilities 
include: 

•  Serves  as  the  USASC  life  cycle  manager  (Combat  Developer)  for  all 
proponent  developmental  systems  and  is  the  principal  USASC  point 
of  contact  for  those  systems 

•  Maintains  an  up-to-date  status  and  continuous  evaluation  of  pro¬ 
ponent  systems  and  related  conceptual,  operational,  organizational, 
training,  testing  and  funding  actions  throughout  the  development 
cycle 

•  Acts  as  the  USASC  action  agency  for  all  life  cycle  development 
events  which  are  not  the  functional  responsibility  of  other  USASC 
activities 

t  Prepares  and  keeps  current  the  USASC  historical  files  for  each 
proponent  system  during  its  development. 
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5_.  Officer  Development  Division,  Directorate  of 
Training  Developments,  USASC.  This  office  is  responsible  for  the  develop¬ 
ment  of  training  materials  which  deal  with  tactical  data  systems. 

£.  Officers  Department,  Directorate  of  Training, 

USASC.  The  PDSS  related  activities  of  this  department  are  concerned  primarily 
with  the  training  of  officers  in  the  use  of  automatic  data  processing  equip¬ 
ment. 


US  Army  Communications-Electronics  (C-E)  Board.  The 
C-E  Board  at  Tort  Gordon  is  one  of  eight  US  Army  test  boards  and  as  such  is 
assigned  the  following  missions  under  TRADOC  Reg.  10-41: 

•  Plan,  conduct,  and  report  on  operational  and  other  user  tests 

■  Participate  in  other  testing  as  directed 

•  Provide  advice  and  guidance  on  test  matters  to  combat,  training, 
and  materiel  developers,  other  services,  and  private  industry 

•  Conduct  other  tests  and  selected  evaluations  as  directed  by  CG 
TRADOC. 


8.  TRADOC  System  Manager  (TSM)  for  Army  Data  Distribution 
System  and  Mobile  Subscriber  Equipment  (ADDS/MSE).  The  mission,  authority,  and 
responsibilities  of  the  TSM-ADDS/MSE  are  spelled  out  in  the  TRADOC  System  Manager 
Charter,  Army  Data  Distribution  System  and  Mobile  Subscriber  Equipment  (ADDS/MSE), 
dated  16  November  1979.  By  this  charter,  his  mission  is  to  conduct  total  system 
management  for  ADDS  and  MSE  within  TRADOC.  In  terms  of  PDSS  this  TSM  will  be 
responsible  for  identifying  and/or  communicating  doctrinal  changes  which  necess¬ 
itate  enhancements  in  the  system  or  which  may  represent  a  new  requirement  thereby 
requiring  major  software,  firmware,  or  hardware  changes. 

9_.  TRADOC  System  Manager  (TSM)  for  Army  Tactical  Communi¬ 
cation  Systems  (ATACS).  The  mission,  authority,  and  responsibilities  of  the 
TSM-ATACS  are  spelled  out  in  a  TSM  Charter  dated  June  1978.  By  this  Charter, 
his  mission  is  to  conduct  total  system  management  for  ATACS  within  TRADOC.  For 
these  systems,  TSM-ATACS  is  ensuring  that  User  requirements  are  being  satisfied 
in  terms  of  operational  and  organizational  concepts,  hardware,  software, 
training,  fielding,  and  integrated  logistical  support. 

10.  TRADOC  System  Manager  (TSM)  for  Tactical  Automatic 
Switches  (TAC  AU  SW"5T  The  TSM-TAC  AU  SW,  operating  under  a  TSM  Charter,  is 
conducting  total  system  management  within  TRADOC  for  Tactical  Automatic  Switches. 
He  is  providing  User  representation  for  the  AN/TTC-39,  the  AN/TYC-39,  and  the 
AN/TSQ-1 1 1 ( V) . 
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1 1 .  TRADOC  System  Manager  (TSM)  for  Tactical  Satellite 
Communications  (TACSATCOM).  The  TSM-TACSATCOM,  operating  under  a  TSM  Charter 
dated  10  September  1978,  is  conducting  total  system  management  within  TRADOC 
for  Tactical  Satellite  Communications.  All  of  the  systems  for  which  he 
currently  is  providing  User  representation  are  Category  3. 

12.  TRADOC  System  Manager  (TSM)  for  Test  Measurement 
Diagnostic  Systems  TTMDS).  The  TSM-TMDS  was  recently  designated  and  does  not 
yet  have  a  formal  charter  from  TRADOC  although  a  draft  charter  has  been  approved. 
TSM-TMDS  will  conduct  total  system  management  within  TRADOC  for  TMDS. 

1 3.  TRADOC  System  Manager  (TSM)  for  Position/Navigation 
(TSM-POS/NAV) .  The  TSM-POS/NAV  is  located  at  Fort  Leavenworth.  This  TSM  is 
responsible  for  conducting  total  system  management  within  TRADOC  for  the 
NAVSTAR  Global  Positioning  System  (GPS),  the  Position  Location  Reporting 
System  (PLRS),  the  Integrated  Inertial  Navigation  System  ( I I NS ) ,  the  Light¬ 
weight  Doppler  Navigation  System  (LDNS),  the  Self-Contained  Vehicle  Land 
Navigation  System  (VLNS),  and  the  Position  and  Azimuth  Gyro,  Lightweight 
(SIAGL).  The  functions  of  the  TSM  are  stated  in  CAC  &  Fort  Leavenworth 
Reg.  10-1,  dated  1  August  1980. 

(b)  BAS  to  be  supported.  The  Category  1  and  2  BAS  to  be 
supported  at  USASC  &  FG  are  listed  in  Figure  2-18.  Included  in  parentheses 
behind  each  system  name  is  the  current  life  cycle  status  of  that  system. 

(3)  The  Objective  System. 

(a)  Purpose  &  scope.  The  Objective  PDSS  System  described  here 
is  intended  to  provide  those  capabilities  needed  to  adequately  fulfill  all 
Combat  Developer  PDSS  responsibilities  for  battlefield  automated  systems  (BAS) 
in  the  Communications  Functional  Area  through  1987.  This  description  is  to 
serve  as  a  blueprint  wnicn  the  US  Army  Signal  Center  (USASC)  can  follow 

and  refine  in  its  detailed  PUSS  implementation  effort. 

(b)  Principal  features.  The  Objective  PDSS  System  proposed 
for  the  Signal  Center  can  be  characterized  as  adding  the  necessary  PDSS  cap¬ 
abilities  with  a  minimum  of  new  organizational  structure.  Wherever  possible, 
these  capabilities  are  added  as  an  augmentation  within  the  existing  structure. 

The  result  incorporates  features  of  both  CD  PDSS  Generalized  Models  1  and  2, 
illustrated  in  Figures  2-2  and  2-3.  Principal  augmentations  and  other 
changes  needed  to  achieve  the  Objective  PDSS  System  are: 

t  Addition  of  a  new  division  within  the  Directorate  of  Combat 
Developments.  To  be  known  as  the  Software  Support  Division, 
this  organizational  element  will  be  dedicated  to  PDSS  functions 
and  will  also  provide  a  central  focal  point  for  PDSS  actions 
which  may  be  dispersed  in  other  elements. 
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FUNCTIONAL 

PROPONENT 

BATTLEFIELD 

AUTOMATED 

SYSTEM  (BAS) 

USASC 

PLRS — POSITION  LOCATION 

REPORTING  SYSTEM  (FULL  SCALE  DEVELOPMENT) 

USASC 

JTIDS— JOINT  TACTICAL  INFOR¬ 
MATION  DISTRIBUTION  SYSTEM  (FULL  SCALE  DEVELOPMENT) 

USASC 

PLRS/JTIDS  HYBRID  (VALIDATION) 

USASC 

DLDED— DIVISION  LEVEL  DATA 

ENTRY  DEVICE  (CONCEPTUAL) 

USASC 

AN/TTC- 39— AUTOMATIC  TELE¬ 
PHONE  CENTRAL  OFFICE  (FULL  SCALE  PRODUCTION) 

USASC 

AN/TYC- 39— AUTOMATIC  MESSAGE 

SWITCHING  CENTER  (FULL  SCALE  PRODUCTION) 

USASC 

AN/UGC-74A(V)—  MOOULAR 

RECORD  TRAFFIC  TERMINAL 
(MRTT)  (FULL  SCALE  PRODUCTION) 

USASC 

AN/TSO-m  (V) —  COMMUNICATION 

NODAL  CONTROL  ELEMENT  (CNCE)  (FULL  SCALE  DEVELOPMENT) 

USASC 

AN/TTC-38— AUTOMATIC  TELE¬ 
PHONE  CENTRAL  OFFICE  (FULLY  OPERATIONAL) 

USASC 

AN/HSH-105— ' TEST  AND  AUTO¬ 
MATIC  REPAIR  FACILITY  (LOW  RATE  INITIAL  PRODUCTION) 

Figure  2-18.  Principal  systems  requiring  PDSS--Communications  Functional  Area 
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•  Establishment  of  a  liaison  office  at  Fort  Monmouth  to  ensure  con¬ 
tinuity  of  contact  with  the  various  key  Materiel  Developer  and 
other  organizations  in  chat  immediate  area,  and  supplementing  the 
TDY  and  other  forms  of  contact  and  communication. 

•  Limited  augmentation  of  the  Materiel  Systems  Development  Division. 
This  augmentation  will  be  that  necessary  to  ensure  that,  between 
the  personnel  in  this  division  and  the  TRADOC  System  Manager 
offices,  a  designated  CDSM  can  be  maintained  for  each  system  whose 
PDSS  requirements  warant  such  a  designated  responsibility. 

0  Limited  augmentation  of  the  Systems  Integration  Management  Office 
(SIMO)  of  DCD.  This  augmentation  will  ensure  that  PDSS  functions 
which  are  closely  related  to  those  of  SIMO  can  be  effectively 
coordinated  and  performed  under  the  SIMO  organizational  structure, 
as  appropriate. 

•  Limited  augmentation  of  the  Test  &  Evaluation  Division  of  DCD. 

This  augmentation  will  ensure  that  PDSS  test  and  evaluation  needs, 
including  User  acceptance  and  other  testing,  can  be  effectviely 
coordinated  and  participated  in,  as  necessary,  within  this  division. 

0  Limited  augmentation  of  the  Directorate  of  Training  Developments. 
This  augmentation  will  ensure  that  PDSS  functions  relating  to 
training  device  requirements,  training  device  software,  and  other 
aspects  of  training,  can  be  effectively  coordinated  and  performed 
within  this  directorate. 

0  Addition  of  one  person  (an  03  tactical  communicator  with  expertise 
in  software  support)  to  the  existing  Liaison  Office  maintained  by 
USASC  at  USAREUR.  This  individual  will  provide  a  coordination 
point  for  forward  support,  which  will  be  handled  primarily  on  a 
TDY  basis  with  ad  hoc  teams  from  USASC. 

(c)  Structure.  The  proposed  structure  of  the  Objective  PDSS 
System  at  USASC  is  outlined  in  Figure  2-19.  In  this  figure,  existing  organi¬ 
zational  elements  to  be  augmented  are  marked  with  an  asterisk,  while  new 
organizational  elements  are  highlighted  by  double  lines.  Essentially  all  of 
the  organizational  elements  outlined  in  Figure  2-19  are  participants,  to  some 
degree,  in  carrying  out  PDSS  responsibilities  and  functions.  Such  respon¬ 
sibilities  are  focused  and  coordinated,  however,  in  the  Software  Support 
Division  (SSD)  shown  at  the  bottom  of  that  figure.  Structure  within  the  SSD 
is  shown  in  Figure  2-20.  This  inner  structure  is  designed  to  ensure  (1) 
coordination  of  PDSS  functions  which  can  be  performed  in  existing  organ¬ 
izational  elements  (appropriately  augmented),  (2)  performance  of  remaining 
PDSS  functions,  and  (3)  a  nucleus  of  a  facility,  with  computer  and  computer 
operations  capabilities,  which  can  be  both  used  by  other  elements  of  DCD, 
as  appropriate,  and  also  serve  for  ad  hoc  collection  of  resources  from  various 
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Figure  2-20.  Software  Support  Division  (SSD) 
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elements  as  may  be  necessary  to  address  PDSS  and  PDSS-related  issues  of  the 
various  BAS.  From  Figure  2-20  it  can  be  seen  that  the  SSD  contains  the  Chief, 
SSD,  who  has  directly  reporting  to  him  the  Deputy  Chief,  Technical  Support, 
and  the  following  three  elements: 

•  Plans,  Resources,  Records  Office 

•  Systems  Support  Coordination  Office 

•  Field  Support  Branch 

Reporting  to  the  Deputy  Chief,  Technical  Support,  are  the  following  five 
elements: 

•  Technology  Branch 

•  Requirements  Analysis  &  Engineering  Branch 

t  Software  Analysis  Branch 

•  Modeling,  Simulations,  &  Simulators  Branch 

•  Computer  Support  &  Operations  Branch. 

(d)  Functional  Responsibilities. 

1_.  SSD.  The  overall  mission  of  the  Communications/ 

Data  Systems  Software  Support  Division  (SSD)  is  to  ensure  that  all  CD  PDSS 
responsibilities  and  functions  are  adequately  fulfilled  for  the  Communications 
functional  area.  The  SSD  relies  upon  resources  outside  the  SSD  to  perform 
a  number  of  these  functions,  but  retains  a  coordinating  role  with  respect 
to  those  functions  to  ensure  integrity  of  performance  of  needed  functions. 

The  SSD  performs  the  remaining  PDSS  functions  with  its  own  resources,  which 
include  the  nucleus  of  a  Combat  Developer  Support  Facility  (CDSF)  and  also 
key  analytical  capabilities.  These  internal  SSD  resources  are  also  available, 
as  appropriate,  to  support  system,  system  software  development,  and  system 
life  cycle  management  issues  addressed  by  other  elements  of  the  Directorate 
of  Combat  Developments  and  the  Directorate  of  Training  Developments.  The 
responsibilities  of  the  elements  of  the  SSD  are  outlined  below. 

a.  Chief,  SSD.  The  Chief,  Communications/Data 
Systems  Software  Support  Division,  reports  to  the  Director,  Combat  Develop¬ 
ments  and  is  responsible  for  carrying  out  the  basic  mission  of  the  SSD, 
through  both  internal  SSD  and  other  resources  at  USASC,  and  by  fostering  a 
climate  of  cooperation  with  the  various  elements  external  to  USASC  with 
which  the  SSD  must  interface. 

b.  Plans,  Resources,  Records  Office.  The  Plans, 
Resources,  Records  Office  of  the  SSD  reports  to  the  Chief  and  is  the  focal 
point  for  determination  of  SSD  workload  requirements.  This  office  is  also 
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responsible  for  preparing  and  maintaining  policies  and  plans  for  acquisition, 
separation,  and  effective  use  of  all  resources  within  the  SSD,  in  coordin¬ 
ation  with  other  USASC  resources.  Included  in  this  responsibility  is  ensuring 
that  all  appropriate  educational  and  training  avenues  are  effectively  used 
in  achieving  and  maintaining  necessary  skills  among  SSO  personnel.  This 
office  will  help  ensure  that  both  man-machine  interface  technology  and  con¬ 
figuration  management  policies  are  appropriately  addressed  in  the  work  of 
the  SSD,  and  will  maintain  all  necessary  official  correspondence  and  other 
necessary  records  pertaining  to  BAS  under  purview  of  the  SSD. 

c_.  Systems  Support  Coordination  Office.  The  Systems 
Support  Coordination  Office,  in  support  of  the  Chief,  SSD,  maintains  contact 
with  the  CDSMs  designated  for  individual  BAS,  or  groups  of  BAS,  as  may  be 
appropriate,  and  thereby  helps  to  facilitate  the  allocation  of  resources 
within  the  SSD  and  elsewhere  at  USASC  to  the  PDSS  needs  of  individual  CDSMs. 
This  office  also  is  responsible  for  identifying  BAS  requiring  designation  of 
a  CDSM,  and  will  monitor  the  PDSS  addressal  of  the  various  BAS  in  this 
functional  area,  for  the  purpose  of  making  appropriate  recommendations  to 
the  Chief,  SSD. 


d.  Field  Support  Branch.  The  Field  Support  Branch 
is  responsible  for  developing,  coordinating,  and  maintaining  plans  for  nec¬ 
essary  field  support  of  BAS  under  purview  of  the  SSD.  Such  field  support 
will  include  providing  guidance  to  users  of  BAS,  introducing  change  packages, 
and  providing  crisis  or  wartime  support.  This  branch  will  provide  limited 
resources,  and  will  manage  these,  in  coordination  with  other  resources,  to 
help  fulfill  necessary  field  support  functions.  This  branch  will  provide 
essential  travel  and  logistical  support  to  traveling  PDSS  teams  from  USASC, 
and  will  maintain  contact,  as  appropriate,  with  served  user  units  or  other 
facilities  where  field  support  is  required.  Generally,  field  visits  will  be 
on  an  ad  hoc  basis,  with  participants  selected  from  various  parts  of  SSD 
other  parts  of  OCD,  or  from  DTD,  as  needed.  The  introduction  of  software 
change  packages  and  new  equipment  training  (NET)  is  performed  in  conjunction 
with  counterpart  Materiel  Developer  teams. 

e.  Deputy  Chief,  Technical  Support.  The  Deputy 
Chief,  Technical  Support,  in  addition  to  responsibilities  which  may  be 
assigned,  as  required,  by  the  Chief,  SSD,  is  responsible  for  ensuring  that 
technical,  engineering,  and  analytical  issues  pertaining  to  the  software 
of  Communications  BAS  are  properly  addressed  and  that  the  necessary 
technical  resources,  within  the  following  five  branches  under  his  direct 
control,  are  available  and  effectively  applied.  The  Deputy  Chief,  Technical 
Support,  will  also  assist  in  coordinating  the  use  of  other  USASC  resources 
toward  fulfillment  of  the  SSD  mission,  and  will,  as  appropriate,  make  his 
own  resources  available  for  other  USASC  tasks. 

f.  Technology  Branch.  The  Technology  Branch  is 
responsible  for  acquiring,  maintaining,  and  analyzing  current  information  in 
the  areas  of  technology  that  could  impact  on  BAS  in  the  Communications 
functional  area.  The  purpose  of  this  analysis  is  to  facilitate  timely 
anticipation  of  impacts  on  these  BAS  and  their  doctrine,  software,  or  soft¬ 
ware  requirements. 
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£.  Requirements  Analysis  &  Engineering  Branch.  The 
Requirements  Analysis  &  Engineering  Branch  is  responsible  for  performing  or 
effecting  that  analysis  necessary  to  identify  the  requirements  for  software 
in  Communications  BAS  and  related  simulators,  and  including  support  software, 
as  may  be  appropriate.  Such  software  requirements  analysis  will  pertain  to 
the  earliest  stages  of  PDSS  planning  for  a  BAS,  as  well  as  the  later  stages, 
including  all  significant  changes  proposed.  This  branch  will  also  assist  in 
and  be  the  focal  point  for  reduction  of  identified  software  requirements 
to  document  forms  which  can  serve  effectively  to  transmit  requirements  to  the 
MD  and  others  for  coordination  and  implementation.  Training  software  re¬ 
quirements  associated  with  BAS  are  included  in  the  responsibilities  of  this 
branch. 


h_.  Software  Analysis  Branch.  The  Software  Analysis 
Branch  is  responsible  for  performing  or  effecting  necessary  functional 
examination  and  analysis  of  software  in  or  pertaining  to  BAS  and  simulators 
under  the  purview  of  the  SSD.  Such  functional  examination  and  analysis 
will  have  the  objective  of  ensuring  that  the  software  in  question  performs 
the  tactical  functions  intended  by  the  user.  This  branch  will  make  use  of 
models,  simulations,  simulators,  and  manual  analysis,  as  well  as  detailed 
examinations  of  the  algorithms  which  implement  tactics  and  doctrine,  to 
achieve  this  objective.  This  branch  will  have  the  capability  to  perform 
such  analyses  as  deemed  necessary  by  the  CDSMs  and  will  be  responsible  for 
recommending  areas  for  such  analysis  to  the  CDSMs  and  others.  This  branch 
will  not  duplicate  the  "verification  and  validation"  work  properly  pre¬ 
formed  by  the  MD,  but  will  obtain  and  take  full  advantage  of  such  work,  as 
necessary.  Teams  within  this  branch  will  specialize  in  particular  BAS  and 
will  be  responsive  to  the  respective  CDSMs.  This  branch  will  prepare 
appropriate  records  of  the  software  analyses  performed. 

i_.  Modeling,  Simulation  &  Simulators  Branch.  The 
Modeling,  Simulation,  &  Simulators  Branch  provides  a  center  of  expertise  in 
the  conception,  development  and  use  of  computerized  models,  simulations, 
system  simulators,  and  necessary  scenarios  or  driver  equipment,  and  also  the 
analysis  of  results  of  their  use,  to  contribute  to  the  analysis  interests  of 
the  CDSMS  and  also  other  elements  of  USASC.  A  section  within  this  branch  will 
prepare  appropriate  scenarios  in  computer- input  form.  Skills  required  in 
this  branch  will  include  operations  research,  systems  analysis,  mathematics, 
electrical  and  electronic  engineering,  computer  science,  communications  and 
Army  communications  management  and  related  doctrine  and  tactics.  Most  of 
the  personnel  in  this  branch  will  be  organized  into  teams,  each  of  which  will 
specialize  in  a  particular  BAS  and  be  responsive  to  the  respective  CDSM.  A 
section  in  this  branch  will  be  devoted  to  anticipating  analysis  requirements 
and  recommending  analysis  approaches  and  techniques  to  the  CDSMs  and  others. 

j_.  Computer  Support  &  Operations  Branch.  The  Com¬ 
puter  Support  &  Operations  Branch  is  to  be  the  nucleus  for  a  Combat  Develop¬ 
er  Support  Facility  (CDSF).  This  branch  is  responsible  for  the  acquisition, 
maintenance  and  disposal  of  all  necessary  computer  resources  local  to  the 
SSD  plus  the  arrangement  or  coordination  of  all  external  computer  resources 
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utilized  by  the  SSD.  Such  resources  include  computers,  peripheral  equipment, 
tapes  or  other  storage  devices,  terminals  and  related  equipment,  key  aspects 
of  the  physical  facility  housing  such  equipment,  models,  simulations,  and 
support  software  for  SSD  research  and  analysis  activities,  plus  personnel 
needed  for  operation  and  maintenance  of  equipment,  models/simulations,  and 
other  related  software,  and  non-BAS  software  documentation.  This  section 
will  include  a  model  maintenance  element,  which  will  assist  in  the  writing 
and  modification/maintenance  of  needed  models/simulations  and  a  support  soft¬ 
ware  element,  which  will  provide  expertise,  software  utilities,  and  other 
items  of  software  which  may  be  needed  to  support  the  work  of  the  SSD. 

2.  Other  elements.  In  this  Objective  PDSS  System,  other 
elements  of  USASC  assume  significant  PDSS  responsibilities.  These  and  other 
elements  are  discussed  below. 

a.  US  Army  Communications-Electronics  Board.  The 
US  Army  Communications-Electronics  Board,  having  operational  control  over  the 
Test  &  Evaluation  Division  of  DCD,  assumes  responsibility  for  coordination  of, 
and  necessary  participation  in,  testing  of  BAS  within  the  purview  of  the  SSD. 

t).  Test  &  Evaluation  Division.  The  Test  and  Evalu¬ 
ation  Division  of  DCD,  which  functions  under  the  operational  control  of  the 
C-E  Board,  is  responsible  for  maintaining  schedules  and  records  of  all  sign¬ 
ificant  testing  performed  or  to  be  performed  at  all  locations  on  BAS  under 
the  purview  of  the  SSD.  This  division  provides  a  nucleus  of  skilled  personnel 
for  participation  in  planning,  observation,  and  analysis  of  system  tests. 

This  division  also  provides  advice  and  assists  in  tests  that  may  be  conducted 
with  SSD  and  other  DCD  or  DTD  resources.  Within  this  division,  teams  will  be 
formed  to  specialize  in  individual  BAS,  as  appropriate.  The  work  of  this 
division  will  be  facilitated  by  the  efforts  of  the  BAS  PDSS  test  &  evaluation 
resources  cooordination  element  to  be  established  at  CACDA. 

c.  USAREUR  Liaison  Office.  The  USASC  Liaison  Office 
at  USAREUR  will  be  augmented  to  assume  a  local  contact,  coordination,  and 
continuity  point  for  forward  support  of  Communications  BAS.  Forward  support 
will  nevertheless  be  performed  primarily  on  a  TDY  basis  by  teams  from  USASC, 
formed  on  an  ad  hoc  basis. 

d.  TRADOC  System  Manager  Offices.  The  TRADOC  System 
Manager  Offices  at  USASC  contain  personnel  from  among  whom  candidates  may  be 
selected  to  serve  as  CDSMs  of  BAS  with  which  they  are  thoroughly  familiar. 

(The  other  principal  source  of  CDSM  candidates  is  the  Materiel  Systems  Develop¬ 
ment  Division  of  DCD.)  Designation  of  a  CDSM  must  be  concurred  in  by  the 
Chief,  SSD.  The  CDSM  is  a  focal  point  for  all  PDSS  activities  pertaining  to 
his  particular  BAS  and  is  also  a  principal  interface  point  for  all  external 
and  internal  communication  regarding  software  in  that  BAS.  The  CDSM  is 
specialized  in  knowledge  of  his  particular  BAS.  He  fosters  similar  knowldege 
among  members  of  the  systems  teams  devoted  to  that  BAS  among  the  various 
tactical  and  technical  functional  elements  of  the  Objective  PDSS  System,  such 
as  concepts  and  studies,  field  support,  requirements  analysis,  and  test  and 
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evaluation.  Under  the  matrix  organization  concept  he  is  the  system  manager 
for  the  activities  of  those  team  members  devoted  to  his  BAS.  He  is  respon¬ 
sible,  in  conjunction  with  the  TRADOC  System  Manager,  if  any,  for  seeing  that 
the  software  of  his  BAS  contributes  most  efficiently  to  overall  system 
effectiveness  and  readiness,  and  he  is  concerned  with  this  systems  software, 
from  User  requirements  through  User  acceptance  testing  and  subsequent  system 
modifications  and  adjustments,  to  include  training  software  and  User  guidance 
on  employment. 


e.  Materiel  Systems  Development  Division.  The 
Materiel  Systems  Development  Division  of  DCD,  provides,  similar  to  the  TSM 
offices,  a  source  of  candidates  for  selection  as  CDSMs  of  BAS  with  which 
they  are  thoroughly  familiar.  The  discussion  of  CDSMs  given  in  the  preceding 
paragraph  applies  also  here. 

f.  Directorate  of  Training  Developments.  Little 
change  from  the  Baseline  System  is  seen  in  the  responsibilities  of  the  Di¬ 
rectorate  of  Training  Developments  (DTD)  and  its  elements,  in  the  Objective 
System.  Close  cooperation  between  DTD  and  the  SSD  will  be  essential  to  take 
full  advantage  of  the  analytical  capabilities  for  PDSS  provided  in  SSD. 

•  £.  Systems  Integration  Management  Office.  The 

Systems  Integration  Management  Office  of  DCD  assumes  responsibility  for  in¬ 
teroperability  analysis  and  engineering  of  Communications  BAS  in  the  Objective 
PDSS  System.  This  responsibility  involves  performing  or  effecting  the  nec¬ 
essary  detailed  examination  and  analysis  of  interoperability  capabilities 
and  limitations  of  BAS  under  the  purview  of  the  SSD.  This  office  will  main¬ 
tain  a  detailed  and  up-to-date  awareness  of  the  interoperability  requirements 
and  characteristics  of  all  BAS  with  which  the  SSD  BAS  may  interface  or  impact 
upon.  Within  this  framework,  this  office  has  the  principal  objective  of 
ensuring  that  potential  interface  problems  are  anticipated  as  early  as 
possible  in  the  BAS  development  life  cycle,  that,  as  BAS  design  and  develop¬ 
ment  proceeds,  these  interfaces  are  properly  accommodated,  and  that,  at  later 
stages,  BAS  code  properly  performs  the  necessary  interface  functions  and  that 
changes  in  any  of  the  interoperating  systems  are  continuously  monitored  and 
evaluated  for  impact.  As  appropriate,  this  office  will  organize  teams  to 
support  the  CDSM-managed  BAS.  The  analytical  capabilities  resident  in  the 
SSD,  particularly  in  the  area  of  simulations  and  simulators,  will  support 
these  efforts  as  appropriate. 

h_.  Concepts  &  Studies  Division.  The  Concepts  & 
Studies  Division  of  DCD  assumes  responsibility  for  providing  a  local  center 
of  expertise  and  information  on  the  detailed,  system-peculiar  tactics  and 
doctrine  of  system  employment  and  operations  of  the  relevant  Communications 
BAS,  based  upon  the  broad  communications  doctrine  provided  by  the  Directorate 
of  Training  and  Doctrine  at  USASC,  and  also  upon  general  doctrine  of  the  Army 
and  other  Services.  This  division  is  responsible  for  coordinating  with  other 
centers  of  doctrinal/conceptual  information  and  developments  in  the  Army  and 
other  Services,  to  ensure  that  both  established  and  advanced  concepts  can 
readily  interplay  in  the  analyses  focused  in  the  elements  of  the  Objective 
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PDSS  System.  Within  this  division  a  team  may  be  formed,  as  appropriate  to 
concentrate  on  each  of  the  principal  communications  BAS  and  to  provide  nec¬ 
essary  assistance  in  this  functional  area  to  the  CDSM  of  that  BAS. 

i_.  CACDA  and  other  elements.  At  Fort  Leavenworth, 
responsibilities  of  CACDA  are  consistent  with  those  enunciated  above,  involv¬ 
ing  the  Force  Level  Control  System  and  the  JINTACCS  Office,  and  the  two  BAS 
PDSS  coordination  elements,  one  for  analysis  resources  and  one  for  test  and 
evaluation  resources.  Through  the  first  of  these  elements,  a  variety  of 
analytical  resources  may  be  available  for  assistance,  such  as  in  the  Combined 
Arms  Studies  and  Analysis  Activity  (CASAA)  at  Fort  Leavenworth,  CACDA' s 
Scenarios  &  Wargames  Directorate,  TRADOC  Systems  Analysis  Activity  (TRASANA) 
at  White  Sands  Missile  Range,  Concepts  Analysis  Agency  (CAA)  of  DCSOPS,  and 
DARCOM's  Battlefield  Systems  Integration  Directorate  (BSI),  at  Alexandria, 
and  Army  Materiel  Systems  Analysis  Agency,  at  Aberdeen.  Test  and  evaluation 
resources  whose  availability  may  be  coordinated,  as  appropriate,  through  the 
second  element  include,  for  example,  the  Tactical  Interoperability  Support 
Element  (TISE)  and  TCATA  at  Fort  Hood,  the  Joint  Test  Element  (JTE)  and  the 
Modular  Automated  Integrated  Systems  Interoperability  Test  and  Evaluation 
(MAINS ITE)  at  Fort  Huachuca,  and  NTC  (Fort  Irwin). 

(e)  Estimate  of  Resource  Requirements.  Estimates  of  resouces 
required  by  the  Objective  PUSS  System  for  the  Communications  functional  area 
are  provided  in  the  following  paragraphs  for  personnel,  major  items  of  equip¬ 
ment,  facilities,  and  funds.  These  estimates  are  time-phased  for  the  fiscal 
years  81-87,  where  possible. 

1_.  Personnel.  Personnel  required  by  the  Objective  PDSS 
System  at  the  USASC  have  been  estimated  by  the  study  team.  These  estimated 
personnel  requirements  are  based  on  consideration  of  the  functions  of  each 
new  organizational  element  within  the  SSD  and  also  the  PDSS  and  related  func¬ 
tions  added  to  the  various  existing  organizational  elements  at  USASC.  The 
resulting  total  requirements  numbers  shown  in  the  top  portion  of  Figure  2-21 
include  only  those  requirements  within  the  Directorate  of  Combat  Developments 
(DCD).  Requirements  of  other  elements  are  indicated  in  the  footnotes  to  that 
figure.  Authorized  personnel  numbers  shown  in  the  middle  of  the  figure  are 
similarly  restricted  to  DCD.  The  last  portion  of  this  figure  shows  additional 
personnel  needed  (required  minus  authorized).  For  FY  87,  a  breakout  of 
personnel  by  major  element  in  the  SSD  is  shown  in  Figure  2-22. 

2_.  Major  Equipment.  A  very  preliminary  identification 
of  major  equipment  items  is  shown  in  Figure  2-23. 

3.  Facilities.  A  very  preliminary  estimate  indicates 
that  new  facilities  may  be  required  for  50  people  and  the  computer  equipment 
and  work  area,  for  a  total  of  13,000  sq.  ft. 

4.  Funds.  A  very  preliminary  estimate  of  DCD  funding 
needed  to  establish  and  operate  the  Objective  PDSS  System  at  USASC  is  based 
on  the  preceding  estimates  and  is  shown  in  Figure  2-24.  Requirements  of 
elements  outside  DCU  are  not  included. 
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COMMUNICATIONS, 

ESTIMATED  PERSONNEL  REQUIRED 

PERSONNEL 

FY  81 

FY  82 

FY  83 

FY  84 

FY  85 

FY  86 

FY  87 

Required 

Military 

22 

24 

27 

30 

32 

33 

33 

Civilian 

16 

17 

19 

21 

22 

22  - 

22 

TOTAL 

38 

41 

46 

51 

54 

55 

55 

Authorized 

Mi  1 i tary 

0 

0 

0 

0 

0 

0 

0 

Civilian 

0 

0 

0 

0 

0 

0 

0 

TOTAL 

0 

0 

0 

0 

0 

0 

0 

Additional 

Needed 

Military 

22 

24 

27 

30 

32 

33 

33 

Civilian 

16 

17 

19 

21 

22 

22 

22 

TOTAL 

38 

41 

46 

51 

54 

55 

55 

Figure  2-21.  Estimated  personnel  required.  Objective 

PDSS  System,  Communications  functional  area 
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ELEMENT 

MANAGERIAL 

AND 

TECHNICAL 

CLERICAL 

AND 

TECHNICIANS 

TOTAL 

MIL 

CIV 

MIL 

CIV 

Office  of  the  Chief,  SSD 

1 

0 

0 

1 

2 

Plans,  Resources,  Records  Office 

1 

1 

1 

0 

3 

Systems  Support  Coordination  Office 

1 

0 

1 

0 

2 

Field  Support  Branch 

3 

1 

1 

1 

6 

Office  of  Deputy  Chief,  Technical  Support 

0 

1 

0 

1 

2 

Technology  Branch 

0 

1 

1 

0 

2 

Requirements  Analysis  &  Engineering  Branch 

2 

2 

2 

0 

6 

Software  Analysis  Branch 

1 

3 

1 

0 

5 

Modeling,  Simulation  &  Simulators  Branch 

2 

4 

3 

0 

9 

Computer  Support  &  Operations  Branch 

1 

3 

5 

1 

10 

LNO,  Fort  Monmouth 

1 

0 

0 

0 

1 

TOTAL  SSD 

13 

16 

15 

4 

48 

Augmentation  of  Existing  Elements: 

LNO,  USAREUR 

1 

0 

0 

0 

1 

Directorate  of  Training  Devel . ,  USASC 

0 

1 

0 

0 

1 

Test  &  Evaluation  Div.,  DCD 

1 

1 

0 

0 

2 

Systems  Integration  Mgt.  Office,  DCD 

1 

1 

0 

0 

2 

Materiel  Systems  Devel.  Div.,  DCD 

2 

0 

0 

0 

2 

TOTAL  AUGMENTATION 

5 

3 

0 

0 

8 

GRAND  TOTAL,  USASC 

T8~ 

19" 

T5~ 

~ 

56“ 

DCD  PORTION  OF  GRAND  TOTAL 

18 

18 

15 

4 

55 

Figure  2-22.  Estimated  personnel  required,  by  element,  FY  1987 


SECURE  TERMINAL  TO  TRADOC  COMPUTER  AT  FORT  LEAVENWORTH 

COMPUTER  &  PERIPHERAL  EQUIPMENT: 

2  -  VAX  11/780,  sharing  extra  900K  memory 
1  -  Line  Printer 

1  -  Disk  Unit 

2  -  Tape  Drives 
1  -  Card  Reader 

4  -  Console/Terminal 


Figure  2-23.  Preliminary  identification  of  major  equipment 
required.  Objective  PDSS  System,  Communications 
functional  area 
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COMMUNICATIONS, 

ESTIMATED  COSTS  ($000)* 

Fiscal  Year 

81 

82 

83 

84 

85 

86 

87 

Devel  opment 
(RDT&E) 

100 

200 

500 

500 

400 

300 

300 

Procurement 

(PA) 

0 

0 

325 

50 

100 

50 

50 

Construction 

0 

0 

1650 

0 

0 

0 

0 

Operations  & 
Maintenence 
(OMA): 

Civilian 

Salaries 

474 

500 

555 

605 

665 

665 

665 

Building 

Modifica¬ 

tions 

0 

50 

50 

25 

25 

0 

0 

Travel  & 
Other 

20 

40 

60 

60 

70 

70 

70 

TOTAL 

"554 

790 

THTo 

1240 

T260 

1085 

TOSS 

♦Constant  FY  81  dollars. 


Figure  2-24.  Estimated  funding  required.  Objective 

POSS  System,  Communications  functional  area 
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e.  Fire  Support  BFA. 

(1)  General ■  The  US  Army  Field  Artillery  Center,  Fort  Sill,  is 
the  proponent  for  this  BFA.  Within  the  Field  Artillery  Center,  the  mission 
and  functions  associated  with  the  Combat  Developer's  role  in  system  develop¬ 
ment  and  life  cycle  management,  to  include  PDSS,  are  primarily  the  respon¬ 
sibility  of  the  US  Army  Field  Artillery  School.  Organizational  elements 
principally  involved  in  fulfilling  these  responsibilities  are  shown  in 
Figure  2-25.  They  include  the  Tactical  Data  Systems  Division,  Combat  Develop¬ 
ments  Directorate;  the  Computer  Test  and  Technical  Support  Division  of  the 
US  Army  Field  Artillery  Board;  and  three  TRADOC  System  Managers.  The  Objec¬ 
tive  PDSS  System  proposed  for  this  BFA  builds  upon  this  existing  organizational 
structure  and  the  current  capability  and  provides  the  improved  capability 
needed  to  fulfill  the  increasing  CD  responsibilities  for  providing  PDSS  to 
BAS  in  this  BFA  through  the  mid-  to  late-1980s.  This  improved  capability  is 
achieved  primarily  through  the  expansion  and  enhancement  of  the  structure  and 
capabilities  of  the  Tactical  Data  Systems  Division  to  form  a  CDSF,  generally 
following  Model  1,  illustrated  in  Figure  2-2.  This  CDSF  will  provide  the 
focal  point  for  addressing  all  PDSS  requirements  of  concern  to  the  Fire 
Support  BFA.  This  includes  coordination  and  interaction  with  the  Materiel 
Developer-managed  PDSS  Centers  that  support  BAS  in  this  BFA.  These  MD-managed 
Centers  include  the  CORADCOM  PDSS  Center  at  Ft  Sill,  the  ERADCOM  and  AVRADCOM 
PDSS  Centers  at  Fort  Monmouth,  the  ARRADCOM  PDSS  Center  at  Picatinny  Arsenal, 
and  the  MICOM  PDSS  Center  at  Redstone  Arsenal . 


(2)  The  current  system.  The  current  system  for  accomplishing  CD 
PDSS  responsibilities  in  this  BFA  is  described  in. general  terms  above. 
Organizational  elements  principally  involved  with  this  system  are  those  shown 
in  Figure  2-25.  The  PDSS-related  functional  responsibilities  of  these  organ¬ 
izations  and  the  BAS  supported  are  discussed  in  the  paragraphs  that  follow. 

(a)  Functional  responsibilities. 

1_.  US  Army  Field  Artillery  School  (USAFAS).  The  principal 
PDSS  related  responsibilities  of  USAFAS  are  to: 


•  Participate  in  the  review  of  doctrine,  organization,  and  equipment 
for  which  training  responsibility  has  been  assigned,  including  the 
development  of  training  plans  to  support  new  items  of  materiel, 
new  organizations,  or  new  tactical  and  technical  concepts 


•  Review  and  evaluate  new  or  revised  doctrine,  tactics,  and  techniques 
prepared  by  other  Army  agencies  or  other  services,  as  appropriate 


Serve  as  the  User  proponent  throughout  the  life  cycle  of  Field 
Artillery  system  materiel.  Serve  as  spokesman  for  the  Field 
Artillery  in  qualitative  interpretations  and  definitions  in  support 
of  the  materiel  development  community 
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US  ARMY  FIELD  ARTILLERY  CENTER  AND  FORT  SILL 


Figure  2-25.  USAFACFS  elements  with  primary  responsibilities 
in  the  current  PDSS  System 
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•  Serve  as  the  principal  Field  Artillery  advisor  to  the  Commander, 
TRADOC. 

2.  The  Tactical  Data  Systems  (TDS)  Division,  Combat 
Developments  (CD)  Directorate  DSAFAS.  This  organization  has  maintenance  and 
support  responsibilities  for  all  Field  Artillery  systems  which  have  reached 
Initial  Operating  Capability  (IOC).  Included  in  these  responsibilities  is 
the  front-end  evaluation  and  definition  of,  and  establishment  of  requirements 
for,  system  changes  to  meet  User  needs  before  release  to  the  Materiel  Developer. 
The  TDS-CD  also  analyzes  and  develops  requirements  for  training  devices  and 
procedures  for  fielded  BAS  as  software  changes  occur. 

2-  US  Army  Field  Artillery  Board  (USAFABD).  The  PDSS 
related  responsibilities  of  USAFABD  are  as  follows: 

•  Plan,  conduct,  and  report  on  Operational  Test  I,  Operational  Test 
II,  Operational  Test  III,  and  any  other  User  type  tests  of  Field 
Artillery  materiel 

•  Participate  in  Development  Test  I,  Development  Test  II  (Engineering 
Phase),  and  Development  Test  III  as  directed 

•  Provide  advice  and  guidance  on  test  and  evaluation  matters  to 
materiel  developers,  materiel  producers,  other  services,  and 
private  industry 

•  Conduct  other  tests  and  evaluation  as  directed  by  Commander,  TRADOC. 

On  10  August  1977,  the  USAFABD  was  designated  by  HQ  TRADOC  (via  TRADOC  Msg, 
ATCD-TM,  101918Z  Aug  77,  subject:  TACFIRE  Tape  Validation)  as  the  responsible 
agency  for  User  validation  of  TACFIRE  system  master  tapes  developed  by  the 
DARCOM  TACFIRE  Software  Support  Center,  Fort  Sill.  In  accordance  with  this 
tasking,  the  Software  Validation  Branch,  Test  and  Technical  Support  Division, 
USAFABD,  has  been  performing  acceptance  testing  of  new  TACFIRE  software  re¬ 
leases.  Depending  on  requirements,  this  testing  has  been  or  can  be  operational 
testing,  developmental  testing,  or  command  post  exercise  oriented.  In  addition 
to  its  testing  responsibilities,  this  organization  is  also  a  member  of  the 
local  Software  Configuration  Control  Board. 

4.  TRADOC  System  Manager  (TSM),  Field  Artillery  Tactical 
Data  Systems  (FATDS).  The  mission,  authority,  and  responsibilities  of  the 
TSM-FTAOS  are  spelled  out  in  the  TRADOC  System  Manager  Charter,  Field  Artillery 
Tactical  Data  Systems  (FATDS),  dated  1  November  79.  By  this  charter,  his 
mission  is  to  "conduct  total  system  management  within  TRADOC  for  FATDS  to 
include  TACFIRE,  Batter^  :mputer  System  (BCS),  Digital  Message  Device  (DMD), 
and  other  follow-on  system  enhancements".  One  of  the  responsibilities  of  the 
TSM-FATDS  which  is  delineated  in  that  charter  is  "managing  the  TRADOC  aspects 
of  Post-Deployment  Software  Support  (PDSS)  for  FATDS  and  other  Field  Artillery 
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systems  requiring  software  support".  Included  in  these  PDSS  duties  is  coordin¬ 
ation  with  other  organizations  to  ensure  that  plans  for  training,  personnel, 
logistics,  testing,  and  new  doctrine/tactics  are  timely  and  fully  integrated 
into  the  materiel  development  program. 

5_.  TRADOC  System  Manager  (TSM),  Multiple  Launch  Rocket 
System  (MLRS)-Fire  Direction  System  (FDS).  The  TSM-MLRS  monitors  overall 
management  of  the  MLRS-FDS  during  production  and  deployment  phases.  He  acts 
as  User  representative  in  the  writing  of  the  Computer  Resources  Management 
Plan  (CRMP)  for  MLRS-FDS.  He  ensures  User  participation  in  all  Engineering 
Change  Proposals  (ECP).  In  addition,  the  TSM-MLRS  participates  as  a  principal 
member  on  the  TACFIRE/MLRS  Executive  Committee  dealing  with  all  aspects  of 
TACFIRE-FDS  interoperability. 

6_.  TRADOC  System  Manager  (TSM),  Pershing  II  Tactical 
Missile  System  ( PI I ) .  The  TSM-PII  conducts  total  system  management  within 
TRADOC  for  the  Pershing  II.  Due  to  the  life  cycle  status  of  the  PI  I,  he 
currently  has  no  PDSS  activities. 

(b)  BAS  to  be  supported.  The  Category  1  and  2  BAS  to  be 
supported  at  USAFAS  are  listed  in  Figure  2-26.  Included  in  parentheses 
behind  each  system  name  is  the  current  life  cycle  status  of  that  system. 

In  addition  to  these  BAS,  there  are  14  Category  3  BAS,  listed  in  Appendix  C, 
for  which  the  USAFAS  is  proponent. 

(3)  The  Objective  System. 

(a)  Purpose.  The  purpose  of  the  Objective  PDSS  System  des¬ 
cribed  in  this  paragraph  is  to  provide  the  USAFAS  the  capability  to  adequately 
fulfill  its  currently  known  CD  PDSS  responsibilities  through  the  mid-  to 
late~1980s. 


(b)  Principal  features  and  structure.  The  Objective  PDSS 
System  proposed  for  the  Fire  Support  BFA  can  be  characterized  generally  as 
an  expansion  and  enhancement  of  the  existing  structure  and  capability  of  the 
Directorate  of  Combat  Developments,  USAFAS,  to  accomplish  PDSS  functions  that 
are  the  responsibility  of  the  CD.  This  is  accomplished  primarily  through  the 
augmentation  and  expansion  of  the  Tactical  Data  Systems  Division  to  establish, 
staff,  manage,  and  operate  a  CDSF.  The  US  Army  Field  Artillery  Board  is  also 
augmented  in  this  Objective  System  to  provide  an  improved  capability  to  conduct 
and  support  testing  requirements.  The  structure  of  the  expanded  Tactical 
Data  Systems  Division  and  the  relationship  of  this  organization,  and  the  CDSF 
which  it  operates,  to  other  elements  of  the  US  Army  Field  Artillery  Center 
and  School  are  shown  in  Figure  2-27.  As  indicated,  elements  of  the  Tactical 
Data  Systems  Division  include: 

•  A  division  headquarters  element  in  which  the  division  chief  is 
also  designated  the  Chief,  CDSF.  The  TSM,  FATDS  holds  these 
titles  in  addition  to  his  TSM  designation. 
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FUNCTIONAL 

PROPONENT 

BATTLEFIELD 

AUTOMATED 

SYSTEM  (BAS) 

USAFAS 

AN/GSG-10(U) -TACTICAL  FIRE 

DIRECTION  SYSTEM  (TACFIRE)  (PARTIALLY  FIELDED) 

USAFAS 

AN/GYK-29— BATTERY  COMPUTER 

SYSTEM  (BCS)  (DTII) 

USAFAS 

PERSHING  II— TACTICAL 

MISSILE  SYSTEM  (DT/OTI) 

Figure  2-26.  Category  1  and  2  systems  requiring  PDSS  -  Fire  Support  BFA 
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Figure  2-27.  PDSS  organizational  structure,  USAFACFS 
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•  Two  CDSMs  responsible  for  coordinating  PDSS  support  for  two 
groups  of  Fire  Support  BFA  BAS  --  (1)  Artillery  Fire  Control  and 
(2)  Target  Acquisition  and  Missile  Artillery 

•  Three  operating  branches  as  shown  in  Figure  2-27  for  handling  CD 
PDSS  actions 

•  Resources  for  establishing  and  maintaining  contact/liaison  with  MD- 
managed  PDSS  Centers  at  Redstone  Arsenal,  Fort  Monmouth,  and 
Picatinny  Arsenal  that  will  be  supporting  Fire  Support  BFA  BAS. 

(c)  Operating  concept.  The  concept  of  operations  associated 
with  this  Objective  PDSS  System  at  the  US  Army  Field  Artillery  Center  en¬ 
visions  that  PDSS  will  continue  to  be  performed  by  the  Tactical  Data  Systems 
Division  under  cognizance  of  the  Director  of  Combat  Developments.  TRADOC 
System  Managers,  the  Directorate  of  Training  Developments,  and  the  US  Army 
Field  Artillery  Board  will  participate  in  this  PDSS  effort  in  their  respective 
areas  of  functional  responsibility.  The  focal  point  for  this  total  effort 
will  be  the  CDSF  operated  by  the  Tactical  Data  Systems  Division.  Primary 
responsibility  for  a  PDSS  action  would  rest  with  the  CDSM  having  cognizance 
for  the  BAS  being  addressed.  Each  element  of  the  CDSF  would  perform  those 
PDSS  functions  for  which  it  is  responsible,  in  support  of  and  under  the  staff 
coordination  of  the  cognizant  CDSM. 

(d)  Functional  responsibilities.  Under  the  concept  of  this 
Objective  PDSS  System,  the  overall  PDSS  responsibilities  of  the  USAFAS  to 
include  the  Directorate  of  Combat  Developments,  and  those  of  the  US  Army 
Field  Artillery  Board  and  each  of  the  TSMs  would  remain  essentially  the  same 
as  discussed  in  Paragraph  e.(2)(a),  above.  Functional  responsibilities  of 
the  Chief,  Tactical  Data  Systems  Division  and  each  element  of  this  division, 
which  form  the  staffing  of  the  CDSF,  are  discussed  in  the  paragraphs  that 
follow. 


1_.  Chief,  Tactical  Data  Systems  Division  and  Chief, 

CDSF.  Chief,  Tactical  Data  Systems  Division,  Directorate  of  Combat  Develop¬ 
ments  Department,  USAFAS,  is  designated  Chief,  Combat  Developments  Software 
Support  Facility.  As  Chief,  Tactical  Data  Systems  Division,  he  plans,  directs, 
and  manages  all  administrative  and  functional  activities  of  the  div'-ion.  As 
the  Chief  of  the  CDSF  at  Fort  Sill,  he  plans,  directs,  and  supervises  the 
operation  of  the  CDSF  in  accomplishing  its  PDSS  responsibilities  for  BAS  in 
the  Fire  Support  BFA.  He  establishes  priorities  and  allocates  CDSF  resources 
to  address  requirements  for  support  of  all  BAS  functioning  as  a  part  of  the 
Fire  Support  BFA.  He  serves  as  the  primary  point  of  interface  with  the  Chief, 
TACFIRE/FATDS  Software  Support  Group,  and  with  the  President,  US  Army  Field 
Artillery  Board  for  validation  and  acceptance  testing  of  changed  software. 
Specific  functions  of  the  Chief,  CDSF  are  shown  in  Figure  2-28.  The  Chief, 
Tactical  Data  Systems  Division,  must  coordinate  all  software  interoperability 
requirements  which  originate  from  TRADOC  Systems  Managers  of  the  developmental 
Materiel  BAS  functioning  as  a  part  of  the  Fire  Support  BFA. 
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2.  CDSM,  Artillery  Fire  Control  (AFC).  This  CDSM  serves 
as  .the  CD  manager  for  all  PDSS  activities  associated  with  artillery  fire 
control  systems.  Included  in  this  group  are  one  Category  1  system  (TACFIRE/ 
FATDS)  and  one  Category  2  system  (BCS),  and  five  Category  3  systems.  The 
CDSM,  AFC  is  the  system  software  Combat  Developer  and  the  principal  User's 
representative  for  these  systems.  As  such,  he  is  responsible  for  planning, 
programming,  and  coordinating  those  PDSS  functions  to  be  performed  by  the 
CDSF  in  support  of  his  systems.  Specific  functions  with  which  he  is  involved 
in  either  a  management,  coordination,  or  performance  role  are  listed  in 
Figure  2-28. 


3_.  CDSM,  Target  Acquisition  and  Missile  Artillery. 

This  CDSM  serves  as  the  CD  manager  for  all  PDSS  activities  associated  with 
target  acquisition  systems  and  missle  artillery  systems.  Included  in  this 
group  is  one  Category  2  system  (Pershing  II)  and  nine  Category  3  systems. 

The  PDSS  responsibilities  and  functions  of  this  CDSM  are  the  same  as  those 
described  previously  for  the  CDSM,  Artillery  Fire  Control  except  for  varia¬ 
tions  imposed  by  differences  in  system  types  and  quantities.  Specific 
functions  of  this  CDSM  are  shown  in  Figure  2-28. 

4.  System  Requirements  and  Analysis  Branch.  This 
branch  of  the  CDSF  is  responsible  for  all  actions  involving  identification, 
analysis,  and  development  of  system  functional  change  requirements  and,  in 
coordination  with  the  two  CDSMs,  stating  these  requirements  to  the  MD.  The 
source  of  these  requirements  may  be  any  system  User  or  cognizant  CD  organiza¬ 
tion.  Analyses  conducted  by  this  branch  in  examining  matters  such  as  system 
problems,  proposed  system  changes,  and  the  impact  of  conceptual  changes  in 
tactics  or  doctrine  on  these  systems  may  be  manual,  computer-assisted,  or 
fully  automated.  Specific  functions  included  in  the  responsibilities  of  the 
System  Requirements  and  Analysis  Branch  are  shown  in  Figure  2-28. 

5..  Interoperabilty  and  Commune i a tions  Support  Require¬ 
ments  (COMSR)  Branch.  The  responsibilities  of  this  branch  focus  on  two  major 
subject  areas.  The  first  area  is  interoperability.  In  this  area,  the  branch 
analyzes  the  impact  of  functional  changes  on  the  interoperability  of  the 
system.  It  identifies  interoperability  change  requirements  which  result  from 
either  changes  to  a  fire  support  BAS  or  changes  to  another  system  with  which 
the  fire  support  BAS  must  interoperate.  The  second  area  of  responsibility  for 
this  branch  concerns  communications  support  requirements  (COMSR).  In  this 
area,  the  branch  establishes  and  maintains  requirements  for  communications 
between  target  acquisition  systems  and  fire  control  systems  and  with  external 
systems.  It  also  analyzes  the  impact  of  adding  new  target  acquisition  or 
fire  control  systems  to  its  communications  network. 

6.  Tactical  Simulation  Branch.  This  branch  of  the  CDSF 
has  responsibility  for  preparing  and  conducting  all  simulations  needed  by  the 
CD  during  front-end  requirements  analysis.  Preparation  of  the  simulations  may 
include  the  design  and  development  of  experimental  software  to  test  basic 
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Figure  2-28.  Assignment  of  functions.  Objective  PDSS  System,  Fire 
Support  BFA  (continued  on  next  page) 
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concepts,  the  collection  of  data,  the  building  of  automated  data  bases,  and 
the  generation  of  scenarios  to  drive  the  simulations.  Since  much  of  this 
work  requires  computer  support,  this  branch  has  a  requirement  for  either 
direct  or  remote  access  to  computer  resources. 

7_.  PDSS  Liaison.  The  Objective  PDSS  System  for  the 
Fire  Support  BFA  provides  the  capability  to  maintain  essential  contact/ 
liaison  with  geographically  separated  PDSS  Centers  which  support  Fire 
Support  BFA  BAS.  These  PDSS  centers  include: 

a.  Redstone  Arsenal.  The  MICOM  PDSS  Center  supports 
four  missile  Artillery  systems  listed  in  Appendix  C. 

b.  Picatinny  Arsenal.  The  ARRADCOM  PDSS  Center 
support  three  Artillery  fire  control  systems  listed  in  Appendix  C. 

c.  Fort  Monmouth.  The  ERADCOM  PDSS  Center  supports 
five  target  acquisition  systems  and  one  fire  control  system  and  to  the 
AVRADCOM  PDSS  Center  for  one  target  acquisition  system  as  listed  in  Appendix 
C. 

(e)  Estimate  of  resource  requirements.  Time-phased  estimates  of 
the  resources  required  to  establish  the  Objective  PDSS  System  in  support  of 
the  Fire  Support  BFA  are  discussed  below. 

1_.  Tactical  Data  Systems  Division. 

Personnel  requirements.  The  estimated  personnel 
requirements  needed  in  the  Tactical  Data  Systems  Division  to  implement  this 
Objective  PDSS  System  are  shown  in  Figure  2-29.  A  breakout  of  these  require¬ 
ments  for  FY  87  by  organizational  element  is  shown  in  Figure  2-30. 

b.  Major  items  of  equipment.  This  CDSF  requires 
either  direct  or  remote  access  to  computer  resources  in  order  to  perform  its 
functions.  In  addition,  computer  access  is  also  required2to  provide  linkage 
with  other  CDSFs  which  support  control  systems  in  the  COS'1  concept.  Specific 
items  of  equipment  required  to  provide  this  access  must  be  determined  during 
initial  implementation  planning. 

£.  Facilities.  Physical  facility  requirements  include 
office  space  for  assigned  personnel  and  floor  space  for  a  computer  and/or 
remote  computer  terminals.  The  physical  space  that  is  required  exists  at 
present  and  is  currently  occupied  by  elements  of  the  Tactical  Data  Systems 
Division.  No  requirements  for  additional  space  are  known  at  this  time. 
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TACTICAL 

DATA 

SYSTEMS  DIVISION,  ESTIMATED  PERSONNEL  REQUIREMENTS 

PERSONNEL 

FY  81  FY  82 

FY  83 

FY  84 

FY  85 

FY  86 

FY  87 

Required 

Military 

17 

19 

19 

21 

21 

21 

21 

Civilian 

11 

12 

12 

13 

13 

13 

13 

TOTAL 

28 

31 

31 

34 

34 

34 

34 

Authorized 

Military 

21 

21 

21 

21 

21 

21 

21 

Civilian 

4 

4 

4 

4 

4 

4 

4 

TOTAL 

25 

25 

25 

25 

25 

25 

25 

Additional  Needed 
Military  -4 

-2 

-2 

0 

0 

0 

0 

Civilian 

7 

8 

8 

9 

9 

9 

9 

TOTAL 

3 

6 

6 

9 

9 

9 

9 

Figure  2-29.  Personnel  requirements,  USAFAS 


ELEMENT 

MANAGERIAL 

AND 

TECHNICAL 

CLERICAL 

AND 

TECHNICIANS 

TOTAL 

Chief,  CDSF 

MIL 

0 

crv 

0 

Mil 

0 

ZW 

0 

0* 

CDSM,  Artillery  Fire  Control 

6 

3 

0 

1 

10 

CDSM,  Target  Acquisition  &  Missile  Artillery 

3 

1 

0 

1 

5 

Systems  Requirements  and  Analysis  Branch 

4 

2 

0 

6 

Interoperability  and  COMSR  Branch 

3 

2 

0 

5 

Tactical  Simulation  Branch 

1 

2 

1 

1 

5 

PDSS  Liaison  Support 

3 

0 

0 

0 

3 

TOTALS 

20 

10 

1 

3 

34 

*  Assumes  utilization  of  staff  currently  assigned  to 

TSM, 

FATDS  office. 

Figure  2-30.  Breakout  of  personnel  requirements 
by  organizational  element 
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d.  Funds.  An  estimate  of  funds  required  for  the 
CDSF  civilian  personnel  requirements  identified  above  is  shown  in  Figure  2-31. 
Funds  needed  for  equipment  and  facilities  are  dependent  upon  development  of 
specific  requirements  during  initial  implementation  planning. 

2.  US  Army  Field  Artillery  Board  (USAFABD). 

a_.  Personnel.  In  order  to  fulfill  its  expanding 
PDSS  responsibilities  in  testing  TACFIRE  update  master  tapes,  the  USAFABD 
will  require  additional  personnel  as  shown  in  Figure  2-32. 

b_.  Major  items  of  equipment  and  facilities.  There 
is  a  need  for  an  Instrumented  Test  Facility  for  use  jointly  by  USAFABD  and 
the  TACFIRE  Software  Support  Group  (TSSG).  This  facility  needs  to  be  funded 
jointly  by  TRADOC  and  CORADCOM  and  could  be  provided  as  an  expanded  capability 
of  the  present  TSSG  (CORADCOM)  machine  room  to  reduce  expenditures. 

£.  Funds.  An  estimate  of  funds  required  in  the  USAFBD 
personnel  identified  above  is  shown  in  Figure  2-33. 
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Civil ian 

Personnel  300.8  332.4  332.4  364.0  364.0  364.0  364.0 


*  In  FY  81  constant  dollars.  Based  on  average  annual  costs  of  $31. 6K, 
including  10  percent  loading,  for  one  technical  civilian  and  $16. OK 
for  one  administrative  level  civilian. 


Figure  2-31.  Estimated  personnel  costs,  USAFAS 
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US  ARMY 

FIELD  ARTILLERY 

BOARD, 

ESTIMATED 

PERSONNEL  REQUIREMENTS 

PERSONNEL 

FY  81 

FY  82 

FY  83 

FY  84 

FY  85 

FY  86 

FY  87 

Required 

Military 

3 

3 

3 

3 

3 

3 

3 

Civilian 

2 

2 

2 

2 

2 

2 

2 

TOTAL 

5 

5 

5 

5 

5 

5 

5 

Authorized 

Mi  1 itary 

0 

0 

0 

0 

0 

0 

0 

Civilian 

0 

0 

0 

0 

0 

0 

0 

TOTAL 

0 

0 

0 

0 

0 

0 

0 

Additional 
Mil itary 

Needed 

3 

3 

3 

3 

3 

3 

3 

Civilian 

2 

2 

2 

2 

2 

2 

2 

TOTAL 

5 

5 

5 

5 

5 

5 

5 

Figure  2-32.  Personnel  requirements,  US  Army 
Field  Artillery  Board 


USAFA8,  ESTIMATED  PERSONNEL  COSTS  ($000)* 


Fiscal  Year 


81 

82 

83 

84 

85 

86 

87 

L  i  v  *  ’  n 

Pe-  -n  ■>! 

63.2 

63.2 

63.2 

63.2 

63.2 

63.2 

63.2 

*  In  CY  81  constant  dollars.  Based  on  average  annual  costs  of  $31. 6K, 
including  10  percent  loading,  for  one  technical  civilian  and  $16. OK 
for  one  administrative  level  civilian. 


Figure  2-33.  Estimated  personnel  costs,  USAFA8 
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f .  Air  Defense  BFA. 

(1)  General .  This  BFA  and  its  PDSS  requirements  are  heavily  in¬ 
fluenced  by  the  major  air  defense  systems  (such  as  Patriot,  TSQ-73,  and 
I-HAWK)  and  the  environment  in  which  they  must  operate.  In  the  integrated 
air  defense  environment  of  NATO,  such  air  defense  systems  must  be  capable  of 
responding,  with  a  minimum  of  human  intervention,  very  rapidly,  to  a  massive, 
high  speed  air  threat.  Both  interoperability  and  response  time  requirements 
are  very  demanding.  Interoperability  requirements  involve  multi-national. 

Air  Force,  and  Other  Service  interfaces  in  addition  to  most  Army  ground  air 
defense  weapon  and  weapon  control  systems.  Response  times,  for  effective 
sequencing  of  events  and  counteractions,  are  measured  in  milliseconds.  To 
achieve  such  response,  human  intervention  must  be  eliminated  wherever  possible 
and,  to  do  this,  large  amounts  of  complicated  decision-making  logic  must  be 
embedded  in  weapons  systems  and  weapons  control  system  software.  If  these 
systems,  including  such  software,  are  not  ready  to  respond  effectively  on 
instant  notice,  the  military  and  political  consequences  could  be  very  grave, 
since  air  defense  in  such  an  environment  is  essentially  the  first  line  of 
defense. 

Ensuring  such  readiness,  places  very  demanding  requirements  on  the  whole 
Combat  Developer-Materiel  Developer  relationship  and  process  throughout  the 
life  cycle  of  individual  and  integrated  air  defense  systems,  including  the 
PDSS  process.  History  has  demonstrated  on  a  number  of  occasions  the  costly 
mistakes  in  system  software  development  which  also  can  seriously  undermine 
the  effectiveness  and  readiness  of  air  defense.  Such  experience  has  shown 
that  advanced  and  extensive  analytical  capabilities  are  necessary  to  properly 
handle  PDSS  responsibilities  for  just  the  several  major  air  defense  systems 
already  in  or  shortly  to  enter  the  inventory— systems  into  which  billions  of 
dollars  have  been  poured  in  recent  years  to  play  air  defense  catch-up  after 
the  Vietnam  years  when  attention  was  turned  elsewhere.  Because  of  the  com¬ 
plexity  of  current  air  defense  systems,  minor  changes  in  tactics  or  proce¬ 
dures,  for  instance,  can  ripple  through  many  stages  of  automated  logic  with 
results  that  are  hard  to  anticipate.  Field  tests  often  cannot  duplicate  the 
battlefield  conditions  of  threat  and  interoperability  necessary  to  uncover 
such  problems.  Therefore,  extensive  capabilities,  in  the  form  of  system  simu¬ 
lators  and  computer  simulations,  and  the  qualified  people  to  use  them,  are 
necessary  to  analyze  interactions  before  system  changes  are  released  to  the 
field  or  incorporated  in  developing  systems. 

The  magnitude  of  the  problem  faced  in  the  Air  Defense  BFA  is  typified 
in  the  Patriot  air  defense  missile  system.  This  system  normally  performs  all 
target  acquisition,  identification,  tracking,  engagement  decision  and  weapon 
assignment,  missile  control,  and  post-intercept  kill  assessment  functions 
automatically,  in  coordination  with  other  AD  weapons  (ground  and  air)  and 
control  systems.  In  addition  to  the  software  required  to  perform  these  tac¬ 
tical  functions,  additional  system  software  supports  personnel  in  maintenance 
operations  and  troop  proficiency  training.  The  tactical  software  portion  of 
the  operations  programs  in  a  fire  unit  of  this  system  involves  over  250,000 
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words  of  instructions  and  data;  a  battalion  control  station  over  190,000 
words;  while  total  Patriot  software  exceeds  five  million  words.  A  contractor 
taskforce,  reaching  a  level  of  well  over  300  workers,  was  devoted  to  develop¬ 
ment  of  the  Patriot  system,  including  its  software.  Combat  Developer  review 
accomplished  so  far  on  the  resulting  software  in  Patriot  has  revealed  200 
questions  or  areas,  each  of  which  calls  for  a  significant  CD  research  and 
analysis  project.  These  200  projects  on  Patriot  alone  require  a  very  sub¬ 
stantial  set  of  analytical  resources  (operations  research  analysts,  engineers, 
mathematicians,  programmers,  computer  models  and  simulations,  system  simula¬ 
tors,  and  computers  and  other  equipment). 

(2)  The  current  system.  The  current  TRAD0C  Baseline  System  for 
providing  PDSS  in  the  Air  Defense  BFA  has  its  focal  point  in  the  US  Army  Air 
Defense  School  (USAADS),  within  the  US  Army  Air  Defense  Center  and  Fort  Bliss, 
at  Fort  Bliss  Texas.  There  the  principal  action-level  element  is  the  Combat 
Systems  Software  Division  (CSSD),  in  the  Directorate  of  Combat  Developments. 
Other  TRAD0C  elements,  both  at  USAADS  and  at  other  installations,  are  actively 
involved  in  the  Baseline  System.  Outside  of  TRAD0C,  elements  of  DARC0M,  the 
Users  of  Air  Defense  systems,  the  US  Army  Research  Institute,  and  various  con¬ 
tractors  are  involved  in  the  Baseline  PDSS  System  either  actively  or  as  inter¬ 
face  points.  Figure  2-34  delineates  the  organizational  structure  of  the  TRAD0C 
elements  of  the  Baseline  PDSS  System  at  Fort  Bliss.  Figure  2-35  shows  the 
structure  of  the  total  TRAD0C  Baseline  PDSS  System  for  the  Air  Defense  BFA. 

(a)  Functional  responsibilities.  Overall  responsibilities  of 
USAADS  are  defined  in  USAADS  Reg.  10-1.  Within  USAADS,  the  Directorate  of 
Combat  Developments  (DCD)  is  principally  responsible  for  representing  the 
users  of  air  defense  systems,  developing  system  requirements,  tactics  and,  in 
conjunction  with  the  Directorate  of  Training  and  Doctrine  (D0TD),  developing 
and  implementing  doctrine.  Responsibilities  for  developing  training  materials, 
devices,  and  courses  of  instruction  in  Air  Defense  are  focused  in  the  Director¬ 
ate  of  Training  Developments  (DTD).  Responsibilities  relating  to  software  and 
PDSS  fall  primarily  upon  the  Combat  Systems  Software  Division  (CSSD)  of  DCD, 
and  the  Software  Branch,  within  DTD,  as  indicated  in  Figure  2-34,  above. 

Based  on  USAADS  Reg.  10-1  and  additional  information.  Figure  2-36  summarizes 
and  identifies  principal  USAADS  responsibilities,  working  from  the  general 
level  down  to  the  level  of  software  and  PDSS.  Identified  in  that  figure  are 
those  functions  which  have  particular  relevance  to  PDSS. 

(b)  BAS  to  be  supported.  In  the  first  phase  of  this  study, 
the  BAS  within  the  Air  Defense  BFA  were  reviewed  to  identify  those  which  re¬ 
quire,  or  can  be  clearly  anticipated  to  require,  PDSS.  Seven  specific  BAS, 
plus  an  additional  category,  were  thus  identified,  as  summarized  in  Figure 
2-37. 


(c)  Principal  interfaces.  As  indicated  in  Figures  2-34,  and 
2-35,  discussed  above,  and  Figure  2-38,  below,  the  number  of  TRAD0C  and  other 
elements  involved  in  the  Baseline  PDSS  System  for  the  Air  Defense  BFA  is  very 
substantial.  Thus,  a  multiplicity  of  interfaces  between  elements  is  possible. 
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US  ARMY  AIR  DEFENSE  CENTER  AND  FORT  BLI«r 


Figure  2-34.  TRADOC  elements  of  Baseline  PDSS  System  at  Ft.  Bliss 
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HQ,  US  ARMY  TRAINING  AND  DOCTRINE  COMMAND,  FT.  MONROE,  VA 


•COMMANDING  GENERAL  FT.  LEAVENWORTH,  KS 

nrniirv  rriMMANiniMp  rcMCDAi  1 


Figure  2-35. 


—  COMMAND 
- -  TASKING  AUTHORITY 

Overall  TRADOC  elements  of  Baseline  PDSS  System  for  Air 
Defense  BFA 
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General:  Prepare  and  conduct  courses  of  instruction  for  training 
US  military  and  other  students  in  Air  Defense  Artillery.  Develop 
concepts,  doctrine,  materiel,  and  training  literature;  devise  pro¬ 
cedures  for  their  application  in  operation,  training,  and  mainten¬ 
ance  of  air  defense  weapons  and  control  systems,  personnel,  units, 
and  organization. 

Selected  Functions: 

1.  Conduct  research  and  develop  procedures,  tactics,  and 
techniques  for  the  application  of  approved  doctrine  in 
the  operation,  maintenance,  and  training  of  air  defense 
artillery  units  and  control  systems. 

2.  Develop  doctrine  and  organizational  evaluation  require¬ 
ments,  ana  analyze  test  results  to  determine  the  validity 
of  doctrine  and  organizational  concepts. 

3.  Coordinate  actions  and  conduct  liaison  with  activities 
of  other  major  commands  to  provide  user  guidance  during 
all  phases  of  air  defense  development,  production,  and 
employment  to  ensure  user  interests  are  fully  incor¬ 
porated. 

4.  Act  as  proponent  agency  for  TRADQC  for  all  air  defense 
weapons  systems  and,  as  such,  serve  as  principal  advisor 
and  representative  for  TRADOC  in  areas  of  air  defense 
organization,  doctrine,  training,  tactics,  and  tech¬ 
niques. 

5.  Determine  air  defense  materiel  (system  hardware  and 
software)  requirements  and  provide  user  guidance 
throughout  its  development. 

6.  Coordinate  approved  air  defense  doctrine  with  other 
schools  to  ensure  that  it  is  current  and  encompasses 
the  latest  concepts. 

7.  Develop  training  requirements  and  programs  to  support 
the  introduction  of  new  and  modified  air  defense 
equipment. 

8.  Develop  doctrine  for  employment  and  deployment  of  air 
defense  weapons  and  command  and  control  systems. 


Figure  2-36.  Summary  of  USAADS  mission  &  functions 
(continued  on  next  page) 
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9.  Develop,  optimize,  verify,  and  maintain  system  opera¬ 
tions  and  firing  doctrine  (SYSOPS/FIDOC)  for  current 
and  future  air  defense  weapons  systems  and  command  and 
control  systems,  including  airspace  control  systems. 

10.  Review,  compile,  and  analyze  air  threat  data  and 
conduct  wargames,  simulations,  systems  analysis,  cost 
effectiveness  studies,  and  other  analyses  in  support 
of  air  defense  operational  doctrine,  organizations, 
and  equipment  tests  and  evaluations,  to  include 
training  devices. 

11.  Develop,  improve,  maintain,  and  use  computer  models 
and  data  bases,  and  other  analytical  tools  to  support 
simulations,  wargames,  and  other  analyses  of  air  defense 
systems  and  software. 

12.  Develop  requirements  for  air  defense  training  devices/ 
simulators  (hardware  and  software)  and  training  device 
scenarios. 

13.  Verify  that  software  incorporated  in  air  defense  systems 
correctly  reflects  air  defense  doctrine. 

14.  Insure  compatibility  between  doctrine  incorporated 
into  interrelated  or  interdependent  systems. 

15.  Perform  continuing  analysis  of  suitability  of  air 
defense  doctrine  in  light  of  changing  threat, 
technology,  and  employment. 

16.  Define  and  conduct  operational  and  user  acceptance 
tests  of  air  defense  systems. 


Figure  2-36.  (concluded) 


BATTLEFIELD 
AUTOMATED 
SYSTEM  (BAS) 
AND  STAGE  IN 
LIFE  CYCLE 


PATRIOT  Air  Defense 
Missile  System 
(Limited  Production) 


AN/TSQ-73  (Missile  Minder) 
(Post-Oeployment) 

SHORAD  C2— Short  Range 
Air  Defense  Command  and 
Control  System 
(Early  Concept  Formulation) 


DIVAD  Gun— Division  Air 
Defense  Gun 

(Engineering  Development) 


I -HAWK—  Improved  HAWK 
Air  Defense  Missile  System 
(Post-Deployment  +  New 
Improvements) 


ROLAND— Air  Defense  Missile 
System 

(Advanced  Eng'g  Development) 


ADEWS— Air  Defense 

Electronic  Warfare  System 
(Conceptual  Study) 


Other— Including  AD  Control 
System  for  CCS£ 


Figure  2-37.  Systems  requiring  PDSS— Air  Defense  BFA 
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Figure  2-38. 


Principal  TRADOC  and  other  elements  in  Baseline  PDSS  System 
for  Air  Defense  BFA 
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Because  of  the  central  responsibility  of  USAADS  in  PDSS  for  this  BFA,  however, 
the  principal  PDSS  interfaces  in  this  system  will  tend  to  be  between  USAADS 
(particularly  the  Combat  Systems  Software  Division  of  DCD  and  the  Software 
Branch  of  DTD)  and  other  key  elements.  Such  principal  interfaces  are  summar¬ 
ized  in  Figure  2-39. 

(3)  The  Objective  System. 

(a)  Purpose  and  scope.  The  Objective  PDSS  System  described 

in  this  section  is  intended  to  be  capable  of  adequately  fulfilling  all  CD  PDSS 
responsibilities  and  functions,  looking  forward  into  at  least  the  late  1980's, 
for  the  entire  Air  Defense  BFA.  This  description  is  to  serve  as  a  blueprint 
which  the  US  Army  Air  Defense  Center  and  School  can  follow  and  refine  in  its 
detailed  PDSS  implementation  effort. 

(b)  Principal  features.  The  Objective  PDSS  System  proposed 
for  Air  Defense  closely  resembles  the  CD  PDSS  Generalized  Model  1  discussed 
and  illustrated  above  in  Figure  2-2.  The  Objective  System  is  centered  in  an 
organization  seen  to  logically  evolve  from  the  existing  Combat  Systems  Soft¬ 
ware  Division.  The  resulting  organizational  element,  in  the  Objective  PDSS 
System,  is  labeled  here  as  the  Battlefield  Systems  Software  Support  Organiz¬ 
ation  'BS  u).  The  BS^O  remains  an  integral  element  in  the  structure  of  the 
Directorate  of  Combat  Developments  (DCD).  The  BSJ0  also  remains  a  division- 
level  element,  although  it  embodies  a  very  substantial  increase  in  number  of 
personnel,  over  the  element  from  which  it  evolves,  and  also  directly  addresses, 
from  a  software  viewpoint,  some  functions  also  addressed  in  the  existing 
Materiel  Systems3Di vision  of  DCD.  Internal  structure  stresses  a  matrix  organ¬ 
ization.  The  BS30  provides  for  a  permanent  facility  in  which  some  of  the 
necessary  analytical  personnel  and  the  principal  items  of  equipment  and  related 
tools  (computers  and  peripherals,  simulators,  data  bases,  simulations)  can  be 
centered  to  support  PDSS  and  related  software  systems  research  and  analysis. 

This  Combat-Developer  Support  Facility  (CDSF)  is  based  on  the  CDSF  model  in 
the  PDSS  Concept  Plan  for  BAS,  of  May  1980,  and  serves,  among  other  things,  as 
the  CD  counterpart  of  the  several  MD  PDSS  Centers,  one  of  which  is  maintained 
at  Fort  Bliss  by  MICOM.  In  this  Objective  PDSS  System,  the  BS^O  and  its  CDSF 
operate  in  close  coordination  with  the  coresponding  organizations  at  the  other 
TRADOC  centers  and  schools.  The  CDSF  is  closely  linked  by  special  communications 
with  the  CCS^  activities  at  Fort  Leavenworth  which  control  and  coordinate 
developments  in  all  Control  and  Subordinate  Systems,  one  of  which  is  the  Air  3 
Defense  Control  System,  within  the  overall  Force  Level  Control  System.  The  BS^O 
includes  a  principal  mission  of  supporting  the  requirements  definition,  planning, 
and  support  needs  of  the  existing  Directorate  of  Training  Developments  at  USAADS, 
in  certain  areas.  Foremost  in  these  areas  are  software-containing  training 


In  contrast  to  the  MICOM  and  other  DARCOM  PDSS  Centers,  the  CDSF  is  a 
support  rather  than  an  operating  facility.  The  CDSF  is  an  analytical 
facility  which  contains  the  analytical  tools,  devices,  documentation,  and 
technical  support  personnel  necessary  to  support  all  USAADS  functions  re¬ 
lated  to  BAS  PDSS.  The  MICOM  PDSS  Center,  on  the  other  hand,  focuses  on 
the  technical  and  mechanical  aspects  of  software  production,  documentation, 
and  testing. 
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simulators  and  devices  in  the  Air  Defense  BFA.  Other  TRADOC  elements,  both 
at  Fort  Bliss  and  at  other  installations,  are  active  parts  of  this  Objective 
System.  Outside  of  TRADOC,  there  are  elements  of  DARCOM,  the  Users  of  Air 
Defense  systems,  other  Services  (USAF,  USMC),  NATO,  the  Army  Research  In¬ 
stitute,  and  various  contractors  which  are  involved  in  the  Objective  System, 
either  actively  or  as  interface  points.  For  example,  a  key  element  is  the 
Raytheon  Patriot  Software  Support  Organization  at  Bedford,  Mass.,  which  con¬ 
stitutes  the  MD  PDSS  Center  for  the  Patriot  Air  Defense  missile  system. 

Contact  with  key  elements  in  the  Objective  System  will  be  facilitated,  where 
appropriate,  with  special  communications  means,  such  as  television  conferencing, 
and  high  rate  digital  data  exchange.  No  substitute  is  seen,  however,  for 
on-site  visits  by  those  personnel  from  the  BS^O  who  are  immersed  in  both  the 
specific  issues  of  a  particular  software  system  and  also  the  broader  combat 
developments  environment  of  their  home  base.  Therefore,  substantial  TDY  is 
included  in  resource  requirements.  The  Objective  PDSS  System  is  basically 
a  TRADOC  system,  although  it  must  interact  with,  and  is  heavily  dependent  on, 
many  non-TRADOC  elements. 

(c)  Principal  Elements  Involved.  Principal  elements  involved 
in  the  Objective  PDSS  System  for  the  Air  Defense  BFA  are  identified  in  Figure 
2-40.  This  figure  also  indicates  some  of  the  principal  interfaces  involved, 
thus  providing  a  type  of  system  overview.  Structure  within  the  system  is 
addressed  below.  Other  OARCOM  elements  are  also  involved,  but  are  not  shown 
here  in  Figure  2-40.  Army  combat  modeling/simulation  capabilities  at  three 
separate  locations,  being  developed  under  the  Army  Models  Improvement  Program 
(AMIP)  are  included  in  this  figure.  These  are  the  battalion-level  capability 
at  TRADOC  Systems  Analysis  Agency  (TRASANA),  White  Sands,  the  corps/division 
level  capability  at  the  Combined  Arms  Studies  and  Analysis  Activity  (CASAA), 

Fort  Leavenworth,  and  the  theater-level  capability  at  the  US  Army  Concepts 
Analysis  Agency,  Bethesda.  Also  shown  are  the  CACDA  Scenarios  and  Wargames 
Directorate,  and  the  TRADOC  general  purpose  computer  center  at  Fort  Leavenworth. 
All  of  these  modeling/simulation/gaming  and  computer  elements  are  shown  here 
because  they  are  resources  that  could  contribute  to  the  overall  PDSS  mission. 
Although  these  battalion,  division,  corps,  and  theater  models  and  simulations 
form  an  important  hierarchy  of  analysis  capability,  it  must  be  understood 
that  they  have  very  limited  utility  in  tactical  software  development  and 
analysis,  which  requires  in  almost  all  instances  much  higher  (finer)  resolu¬ 
tion  and  fidelity  than  those  models  and  simulations  possess.  Use  of  these 
and  possibly  other  analysis  resources  will  be  coordinated  through  a  BAS  PDSS 
analysis  resources  coordination  element  established  at  CACDA  in  the  Objective 
System.  Similarly,  requirements  for  inter-BFA  testing  support  will  be  co¬ 
ordinated,  as  appropriate,  through  a  BAS  PDSS  test  &  evaluation  resources 
coordination  element  at  CACDA.  Although  not  indicated  in  the  figure,  re¬ 
sources  for  such  testing  may  include  the  Tactical  Interoperabil ity  Support 
Element  (TISE)  and  TCATA  at  Fort  Hood,  the  Joint  Test  Element  (JTE)  and  the 
Modular  Automated  Integrated  Systems  Interoperability  Test  and  Evaluation 
(MAINSITE)  at  Fort  Huachuca,  ARMTE,  OTEA,  CDEC,  and  NTC  (Fort  Irwin).  USAADS 
will  deal  directly  with  field  units  with  respect  to  ADA  user  testing.  In 
this  context,  it  should  be  stressed  that  test  beds  and  field  tests  have  serious 
limitations  or  disadvantages,  in  many  cases,  for  ADA  system  testing  relevant 
to  software  issues.  Such  limitations  and  disadvantages  include  high  costs  of 
moving  and  using  field  units  and  creating  usefully  realistic  threat  environ- 
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ments,  inabilities  to  capture  essential  test  data  and  freely  reproduce  or 
vary  experiments,  and  timeliness  of  results.  Such  means  cannot  be  justified 
for  many  software  test  questions.  As  a  result,  USAADS  must  depend,  in  large 
measure,  upon  simulations  and  simulators  for  software  testing  analyses. 

Contact  teams  for  forward  support  will  be  formed  on  an  ad  hoc  basis  in  the 
Objective  PDSS  System.  Ad  hoc  teams  will  be  formed  from  appropriate  elements 
under  the  auspices  of  the  Field  Support  Branch.  The  ARRADCQM  DIVAD  Gun 
Software  Support  Office  at  Fort  Bliss  is  a  recommended  element. 

(d)  Structure.  The  macro-structure  of  the  Objective  PDSS 
System  for  Air  Defense  is  illustrated  in  Figure  2-41.  This  macro-structure 
including  such  elements  as  the  US  Army  Air  Defense  Board  and  the  TRADOC 
System  Managers  for  air  defense  systems,  bears  a  close  resemblance  to  the  CD 
PDSS  Generalized  Model  1,  illustrated  in  Figure  2-2.  The  BS^O  is  a  distinct 
and  permanent  element  within  which  dedicated  attention  is  given  to  PDSS  and 
other  software-related  functions.  Also,  a  permanent  Combat  Developer  Support 
Facility  (CDSF)  exists  within  the  Air  Defense  Objective  PDSS  System.  This 
CDSF  is  "owned"  by  an  element  of  the  BS  u  and  a  substantial  portion  of  the 
personnel  and  equipment  of  the  BS40  reside  within  that  CDSF. 

3 

A  more  detailed  illustration,  showing  the  structure  within  the  BS  0,  is 
provided  in  Figure  2-42.  The  internal  organization  of  the  BSJ0  is  seen  to  re¬ 
flect  three  principal  dimensions:  a  dimension  involving  mainly  tactical  exper¬ 
tise,  issues,  and  functions;  a  dimension  involving  largely  technical  expertise, 
issues,  and  functions;  and  a  battlefield  system  dimension,  focusing  on  each  of 
the  principal  air  defense  systems.  In  the  organization  of  the  BSJ0,  these 
three  dimensions  intersect,  in  a  matrix  form,  in  which  the  system  dimension 
cuts  across  the  tactical  and  technical  dimensions.  This  matrix  form  results 
in  the  existence  of  a  system-centered  team,  or  nucleus  of  expertise,  for  each 
principal  system,  appearing' within  each  of  several  functional  branches,  which 
in  turn  are  organized  under  tactical  and  technical  headings. 

(e)  Operating  concept.  The  operating  concept  for  this  Objec¬ 
tive  System  involves  CD  performance  of  CD  functions,  but  in  conjunction  with 
MD  performance  of  MD  functions.  In  fact,  the  basic  mission  of  this  Objective 
System  cannot  be  achieved  without  a  high  degree  of  cooperation  among  CD,  MD, 
and  User  elements  at  many  levels,  in  what  is  essentially  a  common  process. 

The  nature  of  this  process  demands  not  only  coordinated  actions,  including 
joint  forums,  actions,  and  decisionmaking,  but  also,  to  the  maximum  extent 
possible,  collocated  facilities  and  joint  use  of  facilities  and  equipment. 

Items  of  equipment  located  in  the  MD-owned  facility  may  be  a  vital  resource 
for  performance  of  CD  functions,  as  may  be  MD  use  of  equipment  in  a  CD-owned 
facility.  In  many  instances  the  problem  is  a  common  one  requiring  joint 
participation/observation  and  analysis.  In  many  other  aspects  the  MD  and  CD 
functions  require  separate,  different  types  of  equipment  and  analytical  tools. 
Within  the  BSJ0,  the  matrix  form  of  organization  permits  maintaining  a 
system-by-system  project  orientation  within  a  functional  structure.  These 
features  promote  flexibility,  responsiveness,  effective  transfer  of  skills, 
efficient  use  of  resources,  and  cooperation  and  coordination,  but  require 
good  management.  Containing  the  analytical  tools,  devices,  documentation, 
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Figure  2-41.  Macro-structure  of  CD  PDSS  Objective  System  at  Air  Defense  Center. 
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and  technical  support  personnel  necessary  to  support  all  USAADS  functions 
related  to  BAS  POSS,  the  CDSF  is  seen  as  an  analytical  support  facility. 

In  contrast,  MO  PDSS  Centers,  such  as  the  MICOM  facility  at  Fort  Bliss,  are 
seen  as  production  operations  centers  which  focus  on  the  technical  and 
mechanical  details  of  producing,  documenting,  and  verifying  against  specifi¬ 
cations  (at  the  computer  program  code  level)  BAS  software  products ,  which  are 
only  a  part  of  the  total  ADA  system.  The  CDSF,  however,  set  in  the  framework 
of  the  total  ADA  system,  focuses,  with  the  BSJ0,  on  user  needs  and  requirements, 
system  architectures,  and  ADA  system  functional  requirements,  in  terms  of 
both  how  these  can  be  met  by  and  how  they  can  guide  development  of  emerging 
ADA  systems.  In  its  evaluations,  the  CDSF  examines  software  products  only 
down  to  the  level  of  the  algorithms  which  the  computer  code  implements. 

(f )  Functional  responsibilities. 

3 

1_.  BS  0.  The  overall  mission  of  the  Air  Defense  Battle¬ 
field  Systems  Software  Support  Organization  (BS^O)  is  to  ensure  that  all  CD 
PDSS  responsibilities  and  functions  are  adequately  fulfilled  for  the  entire 
Air  Defense  BFA.  Responsibilities  of  the  BSJ0  include  facilitation  of  the 
Combat  Developer's  system  and  system  software  development  and  life  cycle 
management  processes  in  coordination  with  other  elements  of  the  Directorate 
of  Combat  Developments  and  also  the  Directorate  of  Training  Developments. 

The  BS^O  maintains  a  permanent  facility  (CDSF)  which  supports  these  respon¬ 
sibilities.  The  responsibilities  and  functions  of  the  elements  of  the  BSJ0 
are  outlined  below. 

3 

3  a.  Chief,  Air  Defense  BS  0.  The  Chief,  Air  Defense 

BSJ0,  reports  to  the  Director,  Combat  Developments,  US  Army  Air  Defense 
School-  The  Chief  is  responsible  for  carrying  out  the  overall  mission  of 
the  BSJ0,  through  the  resources  at  his  disposal  and  through  fostering  a  3 
climate  of  cooperation  with  the  many  external  elements  with  which  the  BSJ0 
must  interface.  The  Chief  is  also  responsible  for  the  resources  at  his 
disposal,  which  include  the  personnel,  equipment,  and  facilities  involved  in 
the  six  major  elements  of  the  BS^O.  These  major  elements  are: 

•  BS^O  Plans  &  Resources  Office 

•  Standards  &  Records  Office 

•  Tactical  Functions  Office 

•  Technical  Functions  Office 

f  Special  Project  Office 

•  Software  Support  Facility  Branch. 
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~  b.  Deputy  Chief,  Air  Defense  BS^O.  The  Deputy 
Chief,  Air  Defense  BSJ0  carries  the  responsibilities  delegated  to  him  by  the 
Chief,  and  is  to  act  for  the  Chief  in  his  absence  or  as  required. 

c.  BS^O  Plans  and  Resources  Office.  The  §S30  Plans 
and  Resourcas  Office  is  the  focal  point  for  the  determination  of  BSJ0  work¬ 
load  requirements,  and  the  preparation  and  maintenance  of  plans  and  policies 
for  acquisition,  separation,  and  effective  use  of  all  resources  within  the 
BSJ0.  This  function  is  performed  in  coordination  with  superior  elements  as 
well  as  the  elements  within  the  BSJ0.  This  office  also  participates  in 
determining  BS  u  personnel  requirements,  in  planning  for  personnel  acquisi¬ 
tion  and  separation,  and  is  responsible  for  ensuring  that  all  appropriate 
educational  and  training  avenues  are  effectively  used  in  achieving  and  main¬ 
taining  necessary  skills  among  BSJ0  personnel.  A  section  within  this  office 
is  responsible  for  serving  as  a  focal  point  and  assisting  in  analysis  and 
development  of  man-machine  interface  technology  involved  in  the  BAS  under 
purview  of  the  BSJ0.  This  office  will  also  ensure  that  basic  configuration 
management  policies  are  understood  and  adhered  to  throughout  the  BS30. 

d.  Standards  &  Records  Office.  The  Standards^ 
Records  Office  obtains  and  maintains  as  necessary  for  use  within  the  BSJ0 
essential  items  of  documentation  otherwise  not  readily  available  on  the 
systems  under  purview  of  the  BSJ0.  Maintained  by  the  branch  will  be  all 
appropriate  official  correspondence  and,  as  necessary  standards  and  regula¬ 
tions  pertaining  to  the  systems  under  purview.  This  branch  will  also  main¬ 
tain  a  library  of  other  documentation  and  related  materials  commonly  used 
within  the  facility,  and  will  provide  an  appropriate  storage  and  reproduc¬ 
tion  capability  for  all  items.  The  efforts  of  this  branch  are  not  intended 
to  duplicate,  unless  necessary,  the  efforts  of  other  elements. 

e.  Chief,  Tactical  Functions  Office.  The  Chief, 
Tactical  Functions  Office  is  responsible  for  ensuring  that  Air  Defense 
doctrinal  and  tactical  issues  are  appropriately  addressed  within  the  activi¬ 
ties  of  the  BSJ0  and  that  appropriate  information  and  expertise  are  available 
for  that  purpose.  This  responsibility  is  carried  out  with  the  assistance  of 
the  four  branches  which  report  to  the  Chief,  Tactical  Functions  Office.  These 
branches  are: 

•  Systems  Management  Branch 

•  Concepts  and  Doctrine  Branch 

•  Scenarios  Branch 


•  Field  Support  Branch. 
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f.  Systems  Management  Branch.  The  Systems  Manage¬ 
ment  Branch  is  the  central  point  within  the  BS^O  for  activities  pertaining  to 
each  of  the  principal  air  defense  battlefield  automated  systems  (BAS).  For 
each  such  BAS,  a  manager  (CDSM)  is  designated  within  this  branch.  The  CDSM 
is  a  focal  point  for  all  BSJ0  activities  pertaining  to  his  particular  BAS  and 
is  also  the  principal  interface  point  for  all  external  and  internal  communica¬ 
tion  regarding  software  in  that  BAS.  The  CDSM  is  specialized  in  knowledge  of 
his  particular  BAS.  He  fosters  similar  knowldege  among  members  of  the  systems 
teams  devoted  to  that  BAS  among  the  various  tactical  and  technical  functional 
elements  of  the  BS^O,  such  as  concepts  and  doctrine,  field  support,  require¬ 
ments  analysis,  and  test  and  evaluation.  Under  the  matrix  organization  con¬ 
cept  he  is  the  system  manager  for  the  activities  of  those  team  members  devoted 
to  his  BAS.  He  is  responsible  for  seeing  that  the  software  of  his  BAS  con¬ 
tributes  most  efficiently  to  overall  system  effectiveness  and  readiness,  and 
he  is  concerned  with  this  systems  software,  from  User  requirements  through 
User  acceptance  testing  and  subsequent  system  modifications  and  adjustments, 
to  include  training  software  and  User  guidance  on  employment.  In  the  Systems 
Management  Branch,  CDSMs  are  designated  for  the  following  systems: 

•  Patriot 

•  I HAWK 

•  AN/TSQ-73 

•  Roland 

•  DIVAD  Gun 

•  SHORAD  C2 

•  Other/New  Systems. 

The  CDSMs  will  maintain  contact  and  exchange  necessary  information  with 
the  BAS  PDSS  analysis  resources  coordination  element  and  the  BAS  PDSS  test 
&  evaluation  resources  coordination  element  at  CACDA.  Through  these  elements, 
additional  temporary  resources,  for  local  projects,  may  be  arranged  as  appro¬ 
priate  and  as  available  from  other  locations. 

£.  Concepts  and  Doctrine  Branch.  The  Concepts  and 
Doctrine  Branch  provides  a  local  center  of  expertise  and  information  on  the 
detailed  system-peculiar  air  defense  tactical  doctrine  pertaining  to  employ¬ 
ment  and  operations  of  the  relevant  air  defense  systems  in  an  integrated  air 
defense  environment,  such  as  in  NATO,  based  upon  the  broad  air  defense  doc¬ 
trine  provided  by  the  Directorate  of  Training  and  Doctrine,  USAADS,  as  well  as 
Army/other  Services  general  doctrine.  This  branch  is  responsible  for  coordin¬ 
ating  with  other  centers  of  doctrinal/conceptual  information  and  developments 
in  the  Army  and  other  Services,  to  ensure  that  both  established  and  advanced 
concepts  can  readily  interplay  in  the  analyses  focused  in  other  branches. 
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Within  this  branch,  a  team  is  formed  to  concentrate  on  each  of  the  principal 
air  defense  BAS  and  to  provide  necessary  assistance  in  this  functional  area 
to  the  CDSM  of  that  BAS. 


h.  Scenarios  Branch.  The  Scenarios  Branch  is  re¬ 
sponsible  for  acquiring,  maintaining,  and  analyzing  current  information  to 
maintain  an  automated  data  base  on  threats  that  could  impact  on  BAS  in  the 
Air  Defense  BFA,  to  facilitate  timely  anticipation  of  impacts  on  these  BAS 
and  their  doctrine,  software  or  software  requirements.  This  branch  also  con¬ 
tains  a  section  equipped  to  contribute,  as  needed,  to  the  preparation  of 
detailed  scenarios  (in  narrative  and  in  computer- input-ready  form)  for  various 
analysis  and  training  purposes. 

i_.  Field  Support  Branch.  The  Field  Support  Branch 
is  responsible  for  providing  resources,  management,  and  coordination  of  re¬ 
sources  to  help  support  effectively  the  overall  BSJ0  mission  in  the  area  of 
field  support.  Most  of  the  personnel  resources  of  this  branch  will  be  divided 
into  teams,  each  representing  a  particular  BAS  and  operationally  responsive 
to  the  respective  CDSM.  This  branch  will  concentrate  on  the  functions  of 
providing  guidance  to  users  of  BAS,  introducing  change  packages,  including 
training,  and  providing  crisis  or  wartime  support,  to  include  developing, 
coordinating,  and  maintaining  plans  for  such  support.  The  introduction  of 
software  change  packages  and  new  equipment  training  (NET)  is  performed  in 
conjunction  with  counterpart  materiel  developer  teams  (i.e.,  joint  CD/MD 
fielding  team).  This  branch  will  provide  necessary  travel,  logistical,  and 
other  support  to  traveling  teams,  and  will  maintain  contact,  as  appropriate, 
with  served  user  units  or  other  facilities  where  field  support  is  required. 
Generally,  field  visits  will  be  on  an  ad  hoc  basis,  with  participants 
selected  from  various  parts  of  B$J0  as  needed. 

j_.  Chief,  Technical  Functions  Office.  The  Chief, 
Technical  Functions  Office,  is  responsible  for  ensuring  that  technical, 
engineering,  and  analytical  issues  of  air  defense  BAS  software  are  properly 
addressed  and  that  the  necessary  technical  resources  are  available  and 
effectively  applied  to  support  the  BS^O  mission.  This  responsibility  is 
carried  out  with  the  assistance  of  the  six  branches  which  are  subordinate 
to  this  office,  as  follows: 

•  Technology  Analysis  Branch 

•  Requirements  Analysis  &  Engineering  Branch 

•  Interoperability  Analysis  &  Engineering  Branch 

•  Systems/Training  Simulators  Branch 

•  Software  Analysis  &  Maintenance  Branch 

•  Systems  Test  Support  Branch. 


2-90 


These  branches  of  the  Technical  Functions  Office,  while  an  integral  part  of 
the  BSJ0,  are  also  available,  as  appropriate,  to  support  other  DCD  needs. 

These  branches  are  intended  to  provide  a  broad  capability  for  the  intensive, 
sophisticated,  computer-supported,  and  system-technical ly*oriented  research 
and  analysis  necessary  to  effective  fulfillment  of  the  BSJ0  mission.  It  is 
intended  that  this  office  possess  the  expertise,  tools,  and  equipment  or 
access  to  equipment,  necessary  to  fulfill  a  variety  of  key  analysis  functions 
inherent  to  POSS  of  complex  BAS. 

k_.  Technology  Analysis  Branch.  The  Technology 
Analysis  Branch  is  responsible  for  acquiring,  maintaining,  and  analyzing 
current  information  in  the  areas  of  technology  that  could  impact  on  BAS  in 
the  Air  Defense  BFA.  The  purpose  of  this  analysis  is  to  facilitate  timely 
anticipation  of  impacts  on  these  BAS  and  their  doctrine,  software,  or 
software  requirements.  As  appropriate,  this  branch  will  be  organized  into 
teams  addressing  individual  BAS  and  responsive  to  the  CDSM  for  that  BAS. 

1_.  Requirements  Analysis  &  Engineering  Branch.  The 
Requirements  Analysis  &  Engineering  Branch  is  responsible  for  oerforming  or 
effecting  that  analysis  necessary  to  identify  the  requirements  for  software 
in  BAS  and  related  simulators,  and  including  support  software,  a>  may  be  app¬ 
ropriate.  Such  software  requirements  analysis  will  pertain  to  the  earliest 
stages  of  PDSS  planning  for  a  BAS,  as  well  as  the  later  stages,  including 
all  significant  changes  proposed.  This  branch  will  also  assist  in  and  be  the 
focal  point  for  reduction  of  identified  software  requirements  to  document 
forms  which  can  serve  effectively  to  transmit  requirements  to  the  MD  and 
others  for  coordination  and  implementation.  Training  software  requirements 
associated  with  BAS  are  included  in  the  responsibilities  of  this  branch. 

m.  Interoperability  Analysis  &  Engineering  Branch. 

The  Interoperability  Analysis  &  Engineering  Branch  is  responsible  for  per¬ 
forming  or  effecting  the  necessary  detailed  examination  and  analysis  of  in¬ 
teroperability  capabilities  and  limitations  of  BAS  under  the  purview  of  the 
BSJ0.  This  branch  will  maintain  a  detailed  and  up-to-date  awareness  of  the 
interoperability  requirements  and  characteristics  of  all  BAS  with  which  the 
BSJ0  BAS  may  interface  or  impact  upon.  Within  this  framework,  this  branch 
has  the  principal  objective  of  insuring  that  potential  interface  problems 
are  anticipated  as  early  as  possible  in  the  BAS  development  life  cycle,  that, 
as  BAS  design  and  development  proceeds,  these  interfaces  are  properly  accom¬ 
modated,  and  that,  at  later  stages,  BAS  code  properly  performs  the  necessary 
interface  functions  and  that  changes  in  any  of  the  interoperating  systems 
are  continuously  monitored  and  evaluated  for  impact.  As  appropriate,  this 
branch  will  be  organized  in  teams  to  support  the  CDSM-managed  BAS. 

n_.  Systems/Training  Simulators  Branch.  The  Systems/ 
Training  Simulators  Branch  is  responsible  for  the  conception,  development  and 
research  or  analytical  use  of  system  simulators  and  necessary  driver  equipment. 
When  designed  or  used  for  training  purposes,  such  simulators  may  be  called 
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training  simulators  or  training  devices.  The  distinction  between  models  or 
simulations  on  the  one  hand  and  simulators  on  the  other  hand  is  that  the  % 

former  are  representations  of  the  real  system,  at  a  level  of  abstraction  ap¬ 
propriate  to  the  particular  analytical  objectives;  simulators,  however,  will 
duplicate  as  closely  as  possible  either  all  or  selected  features  of  the  real 
BAS.  System  prototypes  may  be  used  for  this  purpose  in  some  cases.  Research/ 
analytical  use  of  simulators  permits  experiencing,  in  advance,  the  types  of 
capabilities  and  problems  which  can  be  encountered  when  the  real  system  is 
employed  in  the  field.  Such  use  of  simulators  is  an  essential  in  performance 
of  the  BS30  mission.  This  branch  will  support  the  Directorate  of  Training 
Developments  in  identifing  the  requirements  for  training  simulators  and  their 
use.  As  appropriate,  most  of  the  people  in  this  branch  will  be  organized  into 
teams,  each  of  which  will  specialize  in  a  particular  BAS  and  be  responsive 
to  the  respective  CDSM. 

o.  Software  Analysis  &  Maintenance  Branch.  The 
Software  Analysis  &  Maintenance  Branch  is  responsible  for  performing  or  effect¬ 
ing  necessary  functional  examination  and  analysis^of  software  in  or  pertaining 
to  BAS  and  simulators  under  the  purview  of  the  BS  u.  Such  functional  examination 
and  analysis  of  software  will  have  the  objective  of  insuring  that  the  software 
in  question  performs  correctly  the  intended  tactical  functions.  This  branch 
will  make  use  of  models,  simulations,  simulators,  and  manual  analysis,  as  well 
as  detailed  examinations  of  algorithms  implementing  tactics  and  doctrine,  to 
achieve  this  objective.  This  branch  will  have  the  capability  to  perform  such 
analyses  as  deemed  necessary  by  the  CDSMs,  and  will  be  responsible  to  recommend 
areas  for  such  analysis  to  the  CDSMs  and  others.  This  branch  will  not  supplant 
or  duplicate  the  "verification  and  validation"  work  properly  performed  by  the 
MD,  but  will  obtain  and  take  full  advantage  of  such  work,  as  necessary.  This 
branch  will  prepare  appropriate  records  of  the  software  analyses  performed. 

Under  the  category  of  software  maintenance,  this  branch  will  perform  similar 
analysis  pertaining  to  any  software  changes  that  may  be  considered  at  later 
stages  in  the  system  life  cycle.  Teams  within  this  branch  will  specialize 
in  particular  BAS  and  be  responsive  to  the  respective  CDSMs. 

£.  Systems  Test  Support  Branch.  The  Systems  Test 
Support  Branch  provides  a  common  focal  point  for  coordination  of  necessary 
BS30  participation  in  testing  of  BAS  within  the  purview  of  the  BS30.  This 
branch  maintains  schedules  and  records  of  all  significant  testing  performed 
or  to  be  performed  on  these  BAS  at  all  locations,  and  provides  a  nucleus  of 
skilled  personnel  for  BS30  participation  in  planning,  observation,  and 
analysis  of  system  tests.  This  branch  also  provides  advice  and  assists  in 
tests  that  may  be  conducted  with  BS30  resources.  Within  this  branch,  teams 
will  be  formed  to  specialize  in  individual  BAS,  as  appropriate.  The  work  of 
this  branch  will  be  facilitated  by  the  efforts  of  the  BAS  PDSS  test  &  evalu¬ 
ation  resources  coordination  element  to  be  established  at  CACDA. 

c^.  Special  Projects  Office.  The  Special  Projects 
Office  contains  a  small  staff  responsible  for  classified  projects. 
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r.  Chief,  Software  Support  Facility  Branch.  The 

Chief,  Software  Support  Facility  Branch,  is  responsible  for  planning,  co¬ 
ordinating,  and  maintaining  the  permanent  facility  (CDSF).  He  is  also  re¬ 
sponsible  for  planning,  coordinating,  and  acquiring  certain  of  the  equipment 
and  personnel  which  are  permanently  resident  in  that  facility  within  the 
following  five  sections  of  the  Software  Support  Facility  Branch: 

•  Facility  Plans  &  Organization  Section 

•  Communications  Section 

•  Facility  Support  Section 

•  Modeling  and  Simulation  Branch 

•  Computer  Support  &  Operations  Section. 

s.  Facility  Plans  &  Organization  Section.  The 
Facility  Plans  &  Organization  Section  is  responsible  for  formulating  and 
coordinating  the  long-  and  short-range  plans  for  the  CDSF,  including  provisions 
to  facilitate  the  effective  use  of  space,  equipment,  and  personnel. 

t_.  Communications  Section.  The  Communications 
Section  is  responsible  for  all  aspects  of  acquisition  and  maintenance  of  ap¬ 
propriate  communications  capabilities  needed  to  provide  the  rapid  (and,  as 
needed,  secure  and  reliable)  interchange  of  digital,  audio,  visual,  and 
graphics  data  or  information  among  the  CDSF,  its  remote  elements,  and  other 
key  interfacing  elements.  Among  required  capabilities  may  be  television 
conferencing,  and  high  bit  rate  audio  or  digital  interchanges. 

u..  Facility  Support  Section.  The  Facility  Support 
Section  is  responsible  for  obtaining  or  providing,  for  the  physical  facility 
and  the  equipment  therein,  any  support  or  expertise3needed,  and  not  otherwise 
provided,  to  permit  the  efficient  conduct  of  the  BS^O  mission.  This  branch 
will  participate  in  the  preparation  and  maintenance  of  resource  plans  for  the 
CDSF. 


Modeling  and  Simulation  Section.  The  Modeling 
and  Simulation  Section  provides  a  center  of  expertise  in  the  development  and 
exercise  of  computerizea  models  and  simulations  and  also  the  analysis  of  model 
or  simulation  results  to  contribute  to  the  analysis  interests  of  the  CDSMs 
and  the  other  branches  in  the  BS^O.  Skills  required  in  this  section  will 
include  operations  research/systems  analysis,  computer  programming,  under¬ 
standing  of  the  scientific  and  engineering  principles  and  characteristics 
of  air  defense  Zr  and  weapons  systems,  and  also  an  understanding  of  air 
defense  system  doctrine  and  tactics.  Most  of  the  personnel  in  this  section 
will  be  organized  into  teams,  each  of  which  will  specialize  in  a  particular 
BAS  and  be  responsive  to  the  respective  CDSM.  A  part  of  this  section  will 
be  devoted  to  anticipating  analysis  requirements  and  recommending  analysis 
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approaches  and  techniques  to  the  CDSMs  and  others.  Models  developed  and/or 
maintained  will  be  in  support  of  other  DCD/DTD  analysis  efforts,  as  well  as 
for  PDSS.  This  section  will  be  responsible  for  the  development  and/or 
maintenance  and  configuration  management  of  models.  A  lesser  degree  of 
simulation  capability  will  have  to  exist  in  other  elements  of  BS^O  to  do 
detailed  analysis  and  explorative  excursions  in  development  of  tactics  and 
doctrine  and  software  requirements  definition. 

w.  Computer  Support  &  Operations  Section.  The 
Computer  Support  &  Operations  Section  is  responsible  for  the  planning  for 
and  acquisition,  maintenance  and  disposal  of  all  computer  resources  local  to 
the  CDSF  plus  the  arrangement  or  coordination  of  all  external  computer  re¬ 
sources  utilized  by  the  CDSF.  Such  resources  include  computers,  peripheral 
equipment,  tapes  or  other  storage  devices,  terminals  and  related  equipment, 
key  aspects  of  the  physical  facility  housing  ch  equipment,  models,  simula¬ 
tions,  and  support  software  for  CDSF  research  and  analysis  activities,  plus 
personnel  needed  for  operation  and  maintenance  of  equipment,  models/simula¬ 
tions,  and  other  related  software,  and  non-BAS  software  documentation.  This 
section  will  include  a  model  maintenance  element,  which  will  assist  in  the 
writing  and  modification/maintenance  of  needed  models/simulations  and  a 
support  software  element,  which  will  provide  expertise,  software  utilities, 
and  other  items  of  software  which  may  be  needed  to  support  the  work  of  the 
CDSF. 


2.  Other  Elements.  The  responsibilities  of  the  USAADS 
Directorate  of  Combat  Developments  and  the  Directorate  of  Training  Develop¬ 
ments  remain,  in  this  Objective  System,  essentially  the  same  as  in  the 
Baseline  System.  At  Fort  Leavenworth,  responsibilities  of  CACDA  are  con¬ 
sistent  with  those  enunciated  in  Paragraph  c,  involving  the  Force  Level 
Control  System  and  the  JINTACCS  Office,  and  the  two  BAS  PDSS  coordination 
elements,  one  for  analysis  resources  and  one  for  test  and  evaluation  re¬ 
sources.  Through  the  first  of  these  elements,  a  variety  of  analytical 
resources  may  be  available  for  assistance,  such  as  in  the  Combined  Arms 
Studies  and  Analysis  Activity  (CASAA)  at  Fort  Leavenworth,  CACDA's  Scenarios 
&  Wargames  Directorate,  TRADOC  Systems  Analysis  Activity  (TRASANA)  at  White 
Sands  Missile  Range,  Concepts  Analysis  Agency  (CAA)  of  DCSOPS,  and  DARCOM's 
Battlefield  Systems  Integration  Directorate  (BSI),  at  Alexandria,  and  Army 
Materiel  Systems  Analysis  Agency,  at  Aberdeen.  The  types  of  test  and  evalu¬ 
ation  resources  that  may  be  available  through  the  second  branch  have  been 
indicated  above. 

(g)  Estimate  of  Resource  Requirements.  Estimates  of  the 
resources  required  to  establish  the  Objective  PDSS  System  for  the  Air  Defense 
BFA  are  discussed  below.  Where  possible,  these  estimates  are  time-phased  for 
the  fiscal  years  81-87.  The  resource  categories  addressed  are  personnel, 
major  items  of  equipment,  facilities,  and  funds. 
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Personnel.  Personnel  needed  to  staff  the  Air  Defense 
Battlefield  Systems  Software  Support  Organization  (BSJ0)  in  the  Objective 
PDSS  System  have  been  estimated  by  the  study  team.  These  estimated  personnel 
requirements  are  based  on  consideration  of  the  responsibilities  of  each 
element  within  the  BS^O  through  the  branch  and  section  level.  Requirements 
for  Directorate  of  Training  Development  personnel  working  in  the  CDSF  or  in 
similar  functions  are  not  included.  The  resulting  total  requirements  figures 
are  shown  by  fiscal  year  in  the  top  portion  of  Figure  2-43.  These  total  re¬ 
quirements,  exclusive  of  DTD,  are  the  numbers  perceived  by  the  study  team 
as  necessary  to  accomplish  all  of  the  functions  identified  above  for  each 
element  of  the  BS'u,  without  consideration  of  what  portion  of  the  work  could 
or  should  be  done  by  contractual  support.  It  is  possible  that  a  beakdown  of 
requirements  into  in-house  and  contractor  personnel  would  yield  slightly 
different  totals,  because  of  the  additional  requirement  for  supervision  of 
contractor  efforts.  The  total  requirements  shown  in  this  figure,  however, 
are  seen  to  grow  from  a  total  of  162  in  FY  81  to  199  in  FY  87.  The  authorized 
personnel  numbers  shown  in  the  middle  of  Figure  2-43  include  only  the  Combat 
Systems  Software  Divison.  The  last  portion  of  this  figure  shows  additional 
personnel  needed  (required  minus  authorized).  For  the  last  fiscal  year,  a 
breakout  of  the  personnel  requirements  is  provided  by  major  organizational 
element  in  Figure  2-44. 

2.  Major  equipment.  Preliminary  identification  of  types 
and  numbers  of  major  equipment  items  required  by  the  Objective  PDSS  System  for 
Air  Defense  is  provided  in  Figure  2-45.  Information  in  that  figure  must  be 
considered  preliminary  because  a  detailed  implementation  planning  study,  needed 
to  yield  definitive  information,  has  not  yet  been  made  for  Air  Defense. 

2-  Facilities.  A  preliminary  estimate  of  facility  space 
requirements  for  the  Objective  PDSS  System  for  Air  Defense,  based  on  the 
BSJ0  and  its  associated  CDSF,  indicates  a  requirement  for  the  entire  space 
within  the  existing  Building  5800  at  Fort  Bliss.  Such  an  occupation  would 
displace  approximately  100  personnel.  Accordingly,  a  rough  estimate  of  new 
construction  cost  has  been  included  in  the  funding  section,  based  on  100 
personnel.  The  estimate  was  based  on  current  applicable  guideline  data  and 
includes  the  building  itself  with  conference  rooms,  the  utilities  and  other 
externals,  equipment  and  furnishings,  and  cost  escalation  for  a  four  year 
approval  cycle. 


£.  Funds.  Estimates  of  funding  needed  to  support  the 
establishment  and  operation  of  the  Objective  PDSS  System  for  Air  Defense 
are  provided  below.  Estimates  provided  by  the  Air  Defense  School  have  been 
reviewed,  rearranged,  and  supplemented  by  the  study  team  to  reflect  the 
activities  of  the  BS^O  and  its  associated  CDSF.  The  resulting  figures  shown 
in  Figure  2-46  are  for  fiscal  years  1981  through  1987,  but  do  not  include 
the  requirements  of  other  elements  at  Fort  Bliss,  such  as  the  Directorate 
of  Training  Developments  (DTD)  or  the  Air  Defense  Board.  DTD  will  require 
contractual  support,  for  PDSS  functions  only,  in  addition  to  the  civilian 
salaries  cost  of  their  PDSS  personnel  requirement  footnoted  in  Figure  2-43, 


ADA,  ESTIMATED  PERSONNEL  REQUIREMENTS 


PERSONNEL 

FY  81 

Fy  82 

FY  83 

FY  84 

FY  85 

FY  86 

FY  87 

Required* 

Military 

68 

82 

97 

97 

97 

97 

97 

Civilian 

94 

98 

102 

102 

102 

102 

102 

TOTAL 

162 

180 

199 

199 

199 

199 

199 

Authorized 

Military 

19 

19 

19 

19 

19 

19 

19  I 

Civilian 

14 

14 

14 

14 

14 

14 

14 

TOTAL 

33 

33 

33 

33 

33 

33 

33 

Additional 

Needed 

Military 

49 

63 

78 

78 

78 

78 

78 

Civilian 

80 

84 

88 

88 

88 

88 

88 

TOTAL 

129 

147 

156 

156 

156 

156 

156 

*  Includes  personnel  in  both  mission-oriented  and  facility  support  funct¬ 
ions  of  combat  development  area.  Requirements  are  total  needed  to  per¬ 
form  all  identified  functions,  without  distinction  as  to  whether  in- 
house  or  by  contract  support--see  text.  Does  not  include  requirements 
within  the  Directorate  of  Training  Development  (DTD)  for  the  following 
numbers  of  civilian  personnel  for  DTD  PDSS  functions,  only,  for  FYs  82 
through  87,  respectively:  2,  5,  6,  6,  7,  7. 


Figure  2-43.  Estimated  personnel  required.  Objective 
PDSS  System,  ADA  BFA 
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MANAGERIAL 

AND 

TECHNICAL 

CLERICAL 

AND 

TECHNICIAN 

TOTAL 

MIL 

CIV 

MIL 

CIV 

Office  of  the  Chief,  BS  0 

BSJ0  Plans  &  Resources  Office 

2 

0 

1 

1 

4 

2 

4 

2 

1 

9 

Standards  &  Records  Office 

0 

2 

2 

1 

5 

Office  of  the  Chief,  Tactical  Functions 

1 

0 

0 

1 

2 

Systems  Management  Branch 

8 

1 

0 

1 

10 

Concepts  &  Doctrine  Branch 

11 

11 

1 

1 

24 

Scenarios  Branch 

7 

5 

5 

1 

18 

Field  Support  Branch 

8 

1 

2 

1 

12 

Office  of  the  Chief,  Technical  Functions 

0 

1 

1 

1 

3 

Technology  Analysis  Branch 

0 

5 

0 

0 

5 

Requirements  Analysis  &  Engineering 

1 

10 

Branch 

3 

6 

0 

Interoperability  Analysis  &  Engineering 

Branch 

4 

6 

0 

0 

10 

Systems/Training  Simulators  Branch 

3 

7 

0 

0 

10 

Software  Analysis  &  Maintenance  Branch 

3 

6 

1 

1 

11 

Systems  Test  Support  Branch 

3 

4 

2 

0 

9 

Special  Projects  Office 

1 

4 

2 

1 

8 

!  Office  of  the  Chief,  Software  Support 

Facility  Branch 

0 

1 

1 

1 

3 

Facility  Plans  &  Organization  Section 

1 

1 

3 

0 

5 

Communications  Section 

1 

2 

2 

0 

5 

Facility  Support  Section 

0 

2 

2 

1 

5 

j  Modeling  &  Simulation  Section 

6 

11 

2 

1 

20 

Computer  Support  &  Operations  Section 

1 

4 

3 

3 

11 

TOTAL 

"65 

“84 

~T2 

199 

Figure  2-44.  Estimated  1987  personnel  requirements  by  element, 
Objective  PDSS  System,  Air  Defense  BFA 
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SECURE  TERMINAL  TO  TRADOC  COMPUTER  AT  FORT  LEAVENWORTH* 

COMPUTER,  MID-SIZE,  WITH  VARIOUS  PERIPHERALS  AND  DATA  LINKS,  TO 
SUPPORT  LOCAL  MODELS  &  SIMULATIONS  AND  TO  INTERFACE 
BETWEEN  SIMULATORS  AND  SELECTED  ITEMS  OF  WEAPON  SYSTEM 
HARDWARE  EMPLOYED  AS  PART  OF  SIMULATION  ENVIRONMENT 

SIMULATORS 

PATRIOT  -  1  SINGLE-CONSOLE  PATRIOT  SIMULATOR  (TOS-T) 
WITH  MINI-COMPUTER* 

-  1  FOUR-CONSOLE  PATRIOT  SIMULATOR  (TOS-4) 

WITH  MINI-COMPUTER** 

I -HAWK  ^ 

DIVAD  GUN  I 

ROLAND  >  NATURE  AND  EXTENT  TO  BE  DETERMINED 
AN/TSQ-73  f 
SHORAD  C2J 

SELECTED  PORTIONS  OF  WEAPON  SYSTEMS  (HARDWARE)  FOR  AD  SYSTEMS 


*  CURRENTLY  ON  HAND-  BEING  UP-GRADED  TO  A  TWO-STATION  DEVICE. 

**  TO  BE  DELIVERED  IN  EARLY  1981.  DOES  NOT  INCLUDE  TRAINING  EQUIP¬ 
MENT  REQUIRED  BY  OR  IN  PROCUREMENT  FOR  DIRECTORATE  OF  TRAINING 
DEVELOPMENT. 


Figure  2-45.  Preliminary  identification  of  major 
equipment  required,  Objective  PDSS 
System,  ADA  BFA 
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ADA,  ESTIMATED  COSTS  ($000)*  -  BS30 


Fiscal  Year 

81 

82 

83 

84 

85 

86 

87 

Development 

(RDT&E) 

Contracts 

830 

550 

2030 

1760 

1400 

200 

200 

Procurement 

(PA) 

- 

- 

2700 

- 

- 

- 

- 

Construction 

(MCA) 

- 

- 

2900 

- 

- 

- 

- 

Operations  & 
Maintenance 
(OMA): 

Civilian 

Salaries 

1058 

1058 

1198 

1198 

1198 

1198 

1198 

Contracts 

1300 

4700 

4440 

4700 

4530 

4590 

4440 

Building 

Modifica¬ 

tions 

. 

150 

150 

100 

100 

100 

i  OY 

150 

150 

298 

314 

264 

264 

264 

Communica¬ 

tions 

50 

50 

50 

50 

50 

50 

50 

Other 

500 

500 

400 

400 

450 

450 

450 

TOTAL 

38S8 

TOO? 

T4T66 

857? 

799? 

6852 

660? 

*  Constant  FY  81  dollars. 


Figure  2-46.  Estimated  funding  required.  Objective 
PDSS  System,  ADA  BFA,  BSJ0  only 
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above.  The  costs  of  required  DTD  PDSS  contractual  support  are  estimated  for 
fiscal  years  1982  through  1987  to  be:  S150K,  $260K,  $350K,  $350K,  $500K,  and 
$500K,  respectively.  These  and  the  DTD  civilian  salaries  for  PDSS  should  be 
added  to  the  numbers  in  Figure  2-46  to  approach  total  Ft.  Bliss  costs  of  the 
Objective  System.  A  brief  indication  of  the  type  of  activity  or  items  covered 
by  the  numbers  shown  in  Figure  2-46  is  given  below  for  each  line  in  the  figure. 

a..  Development  (RDT&E).  Included  in  this  category 
are  contractual  costs  to  develop  detailed,  high-resolution  simulation  models 
of  ADA  systems  and  subsystems.  Such  models  are  essential  to  studies  and 
evaluations  of  the  weapon-specific  doctrine  and  tactics  of  svstem  denlovment, 
co-deployment,  interoperability,  and  employment  as  these  affect  the  software 
embedded  or  to  be  embedded  in  the  systems.  Also  included  are  model  drivers, 
ancillary  data  bases,  and  simulators  (like  the  Patriot  TOS/T)  of  the  tactical 
operations  of  ADA  systems. 

b_.  Procurement  (PA).  This  category  is  for  the 
purchase  of  developed  items  of  hardware  and  associated  software  to  equip  the 
USAADS  software  facility.  Included  are  a  mid-size  computer  with  peripherals, 
analyst  consoles,  color  graphics  consoles,  large  screen  display  unit, 
hardware  to  interface  the  simulation  models  to  tactical  system  hardware  and 
to  system  tactical  operations  simulators,  and  special  integrating  and  support 
software. 


c.  Construction  (MCA).  This  category  is  for  con¬ 
struction  of  a  facility  to  house  people  displaced  by  the  new  organization, 
as  discussed  in  paragraph  (g)^,  above. 

d.  Civilian  Salaries  (DMA).  This  subcategory  of 
Operations  &  Maintenance-Army  is  for  the  non-military  component  of  the 
personnel  requirements  listed  in  Figure  2-43.  The  costs  of  civilian  salaries 
shown  in  Figure  2-46,  however,  are  based  on  about  48  civilians,  which  are 
deemed  by  USAADS  to  represent  that  core  complement  of  in-house  civilian 
personnel  necessary  and  desirable  to  permit  operation  of  the  software 
support  program  with  an  appropriate  mix  of  contractor  support.  For  TRADOC 
budgeting  purposes,  military  pay  and  allowances  (MPA)  are  not  addressed. 

e.  Contracts  (OMA).  This  DMA  subcategory  covers 
contractor  support  in  several  areas.  The  largest  area  involves  provision  of 
about  56  professional  personnel  to  assist  USAADS  in  performance  of  PDSS  and 
related  software  development  tasks,  in  augmentation/in  lieu  of  in-house  re¬ 
sources.  Other  areas  involve  provision  of  technical  advice  and  expertise  in 
specific  ADA  systems  and  their  software  (on  a  full-time  basis),  maintenance 
and  necessary  updating  of  simulation  models  of  ADA  systems,  and  maintenance 
and  necessary  updating  of  system  simulators  such  as  the  Patriot  TOS/T  and 
TOS-4. 


f.  Building  Modifications.  This  subcategory  of  OMA 
is  to  cover  local  Engineer  support  in  modifying  or  converting  portions  of  the 
USAADS  software  facility  to  accomodate  addition  of  computers,  analytical 
equipment/consoles,  and  necessary  rearrangement  of  work  areas. 

£.  TOY.  This  subcategory  of  OMA  is  to  cover  travel 
and  temporary  duty  costs  of  trips  within  and  outside  the  continental  US  as 
required  for  participation  in  software  design  reviews,  contractor  and 
government  testing,  investigation  of  field  user  problems,  user  acceptance 
testing,  introduction  of  new  software  to  the  field,  and  maintenance  of 
contact  and  liaison. 

h_.  Communications.  This  subcategory  of  OMA  is  to 
cover  costs  for  dedicated,  high-speed,  data  quality  leased  lines  between  the 
USAADS  software  facility  and  other  government/contractor  installations.  These 
lines  are  required  for  remote  use  of  large  central  computers  (e.g.,  DPFO, 

Ft.  Leavenworth),  interoperability  testing  with  other  air  defense  systems/ 
facilities,  and  various  types-of  communications  and  tasking  with  other 
systems/facilities  (e.g.,  CCS^  at  Ft.  Leavenworth). 

i_.  Other.  This  subcategory  of  OMA  basically  covers 
supplies  and  other  items  incident  to  the  USAADS  software  facility.  Included 
are  ADP  consumables,  such  as  computer  paper,  service  and  repair  of  ADP 
equipment  and  peripherals,  technical  reference  materials  and  publications, 
and  office  supplies  for  on-site  contractor  personnel. 
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g.  Intelligence  and  Electronic  Warfare  BFA. 

(1)  General .  The  US  Army  Intelligence  Center  and  School  (USAICS) 
is  the  proponent  for  this  BFA.  This  proponency  includes  the  mission  of 
conducting  general  intelligence  and  cryptologic/electronic  warfare  training, 
training  developments,  combat  developments,  and  operational  testing.  Systems 
development  and  life  cycle  management,  to  include  post-deployment  software 
support,  are  carried  out  as  part  of  the  combat  developments  mission.  USAICS' 
organizational  elements  involved  in  performing  Combat  Developer  PDSS  functions 
at  present  are  shown  in  Figure  2-47.  While  these  functions  are  concentrated 
in  the  Directorate  of  Combat  Developments,  other  organizational  elements  shown 
in  the  figure  also  have  significant  roles  in  this  effort.  -These  include  the 
US  Army  Intelligence  and  Security  Board,  four  separate  TRADOC  System  Managers, 
the  Computer  Systems  Management  Office,  and  the  Directorate  of  Training  Develop¬ 
ments  at  both  USAICS  and  the  US  Army  Intelligence  School,  Fort  Devens.  The 
Objective  PDSS  System  proposed  for  this  BFA  has  been  designed  to  take  maximum 
advantage  of  the  existing  and  projected  capabilities  of  these  organizations. 

It  provides  for  the  enhancement  of  these  capabilities  consistent  with  the 
increase  in  PDSS  requirements  anticipated  to  occur  as  additional  Intelligence/ 

EW  BAS  are  deployed  and/or  extended  to  other  Users.  This  needed  improvement 
in  capabilities  is  to  be  achieved  through  augmentation  of  existing  organiza¬ 
tional  elements  involved  with  PDSS  activities,  and  the  establishment  of  one 
new  PDSS  staff  element  within  the  Directorate  of  Combat  Developments.  This 
latter  element  would  provide  the  nucleus  of  a  CDSF  to  be  established  at  USAICS 
as  part  of  this  Objective  PDSS  System.  This  CDSF,  which  would  be  formed 
generally  following  Model  1,  illustrated  in  Figure  2-2,  would  provide  a  focal 
point  for  PDSS  activity  associated  with  Intel  1 igence/EW  BAS.  It  would 
facilitate  coordinating  and  integrating  the  efforts  of  all  USAICS  elements 
who  have  or  should  have  a  role  in  PDSS  actions.  It  would  also  facilitate  the 
USAICS  interface  with  the  two  ERADCOM-managed  PDSS  Centers  that  are  to  support 
Intelligence  and  EW  BFA  systems  under  the  PDSS  Concept  Plan  for  BAS.  One  of 
these  ERADCOM-managed  centers  is  to  be  established  at  Fort  Huachuca  for 
supporting  the  ASAS.  The  other  PDSS  center  for  supporting  all  other  Intelli¬ 
gence  and  EW  BAS  will  be  located  at  Fort  Monmouth. 

(2)  The  current  system. 

(a)  Functional  responsibilities. 

1_.  USAICS.  As  the  TRADOC  proponent  for  tactical  intelli¬ 
gence,  electronic  warfare,  and  intelligence  support  to  operational  security, 
USAICS  is  responsible  for  developing  operational  concepts,  doctrine,  organiza¬ 
tion,  and  materiel  requirements  for  new  intelligence  and  electronic  warfare 
systems  and  units  at  all  echelons  of  the  Army.  This  includes  a  broad  range 
of  functions  associated  with  all  phases  of  the  system  life  cycle,  working  both 
independently  and  in  coordination  with  System  Users,  Materiel  Developers,  Oper¬ 
ational  Testers,  and  others  involved  with  various  aspects  of  intelligence 
systems. 
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Figure  2-47/  Organizational  elements  with  major 

responsibilities  in  the  PDSS  Baseline  System  for 
the  Intelligence  and  EW  BFA 


Z_.  Directorate  of  Combat  Developments.  Within  USAICS, 
primary  responsibility  for  these  functions  is  assigned  to  the  Directorate  of 
Combat  Developments.  Two  divisions  of  this  directorate-the  Concepts  and 
Studies  Division  and  the  Materiel  Division— are  extensively  involved  with 
these  functions.  The  Corps,  Division,  and  EAC/Common  Systems  Branches  of 
the  Materiel  Division  have  action  officers  with  responsibility  for  accom¬ 
plishing  or  coordinating  all  CD  actions  for  specified  intelligence  and 
electronic  warfare  systems  in  their  functional  areas.  The  All-Source  Analysis 
System  (ASAS)  Management  Office  in  the  Directorate  of  Combat  Developments 
discharges  combat  development  responsibilities  inherent  in  the  USAICS  pro- 
ponency  for  the  ASAS  and  related  systems/test  bed  (i.e.,  TCAC,  ADM/SEWS,  and 
BETA).  It  supports  the  TRADOC  System  Manager  for  ASAS  (TSM-ASAS)  (located 
at  CACDA)  as  required. 

3_.  Other  elements.  Other  organizational  elements,  ex¬ 
ternal  to  the  Directorate  of  Combat  Developments,  that  have  major  respon¬ 
sibilities  in  the  current  PDSS  System  include: 

•  The  TSMs  for  Corps,  Division,  and  EAC/Common  Intelligence  and  EW 
Systems,  whose  responsibilities  are  prescribed  in  TRADOC  Reg.  71-12. 

$  The  US  Army  Intelligence  and  Security  Board  which,  under  TRADOC  Reg. 
10-41,  is  responsible  for  monitoring  or  planning,  programming,  and 
supporting  or  conducting  operational  tests  and  other  tests  and  evalu¬ 
ations  as  directed.  This  board  also  provides  advice  and  assistance 
to  the  Directorate  of  Combat  Developments  and  TSMs  on  matters 
associated  with  systems  testing. 

•  The  Directorate  of  Training  Developments,  USAICS,  which  has  training 
development  responsibility  for  all  Intelligence  and  Electronic  Warfare 
systems  except  Signal  Intelligence  systems.  Training  development  for 
these  latter  systems  is  the  responsibility  of  the  US  Army  Intelligence 
School ,  Fort  Devens. 

•  The  Simulation  Systems  Management  Office  of  the  Computer  Systems 
Management  Office  which,  under  a  phased  plan,  is  to  develop  a  cap¬ 
ability  for  providing  automated  support  (e.g.,  simulations  and 
analyses)  to  the  system  development  and  life  cycle  management  effort 
at  USAICS. 

(b)  BAS  to  be  supported.  The  Category  1  and  2  BAS  in  this 
functional  area  that  are  addressed  in  this  study  are  shown  in  Figure  2-48. 

The  stage  of  each  system  in  the  life  cycle  is  also  shown  in  the  figure.  In 
addition,  to  these  Category  1  and  2  BAS,  there  are  11  Category  3  systems 
which  will  also  require  some  CD  participation  in  the  effort  devoted  to  their 
PDSS. 


2-104 


INTELLIGENCE/EW  BFA 


FUNCTIONAL 

PROPONENT 

BATTLEFIELD 

AUTOMATED 

SYSTEM  (BAS) 

USAICS* 

AN/MSC-67— COMMUNICATIONS 

CENTER  (COMFAC) 

(VALIDATION  PHASE) 

USA ICS 

ASAS— ALL  SOURCE  ANALYSIS 

SYSTEM 

(CONCEPTUAL  PHASE) 

USAICS 

AN/TSQ-1 14— TRAILBLAZER 
(PRODUCTION  AND  DEPLOYMENT) 

USAICS 

AN/ALQ-1 51  — QUICKFIX 
(INITIAL  PRODUCTION) 

USAICS 

AN/TSQ-1 05— GUARDRAIL  V 
(PRODUCTION  AND  DEPLOYMENT) 

USAICS 

AN/ALG-1 33— QUICKLOOK  II 
(PRODUCTION  AND  DEPLOYMENT) 

USAICS 

SOTAS— STAND-  OFF  TARGET 
ACQUISITION  SYSTEM 
(FULL-SCALE  DEVELOPMENT) 

USAICS 

TCAC(D) -TECHNICAL  CONTROL 

AND  ANALYSIS  CENTER 
(DIVISION)** 

*  USASC  TO  BECOME  PROPONENT 

AT  THE  TIME  SYSTEM  IS  FIELDED 

**  BEING  DEVELOPED  UNDER 

QRC-51  IAW  AR  105-37. 

Figure2-48.  Intelligence  and  Electronic 
Warfare  Category  1  and  2  BAS 


(a)  Purpose.  The  component  of  the  Objective  POSS  System  des¬ 
cribed  in  this  paragraph  is  to  provide  USAICS  the  capability  to  adequately 
fulfill  its  currently  known  CD  PDSS  responsibilities  for  Intelligence  and  EW 
BFA  BAS  through  the  mid-  to  late-1980s. 

(b)  Principal  features.  This  Objective  System  can  be  char¬ 
acterized  generally  as  an  enhancement  of  USAICS'  current  capability  to 
accomplish  those  PDSS  functions  that  are  the  responsibility  of  the  CD.  This 
enhancement  is  to  be  accomplished  through  the  following  steps: 

•  Establishment  of  a  CDSF  at  USAICS  in  conjunction  with  the  ERADCOM- 
managed  PDSS  Center  that  is  to  be  established  there.  This  CDSF 
would  be  formed  along  the  lines  of  Model  1,  illustrated  in 
Figure  2-2. 

•  Establishment  of  a  PDSS  Staff  Element  within  the  Directorate  of 
Combat  Developments  to  operate  and  form  the  nucleus  of  the  CDSF. 

•  The  augmentation  of  certain  existing  USAICS  organizational  elements 
with  additional  personnel  to  provide  these  organizations  an  improved 
capability  to  perform  or  support  CD  PDSS  actions.  The  organiza¬ 
tional  elements  are: 

••  The  All-Source  Analysis  System  Management  Office 

•#  The  Corps,  Division,  and  EAC/Common  Systems  Branches  of  the 
Materiel  Division 

te  The  Test  and  Evaluation  Coordination  Branch  of  the  Materiel 
Division 

#•  The  Systems  Integration  Branch  of  the  Concepts  and  Studies 
Division 

••  The  News  Systems  Branch  of  the  Individual  Training  Division, 
Directorate  of  Training  Developments. 

•  The  designation  of  CDSMs  for  ASAS  and  for  other  Corps,  Division, 
and  EAC/Common  Intelligence  and  EW  BAS. 

The  proposed  new  PDSS  Staff  Element,  called  the  Combat  Developments  Support 
Office,  would  be  subordinate  to  the  Director  of  Combat  Developments.  This 
office  would  form  the  nucleus  and  principal  functional  operating  element  of 
the  proposed  USAICS'  CDSF.  It  would  provide  a  focal  point  for  coordination 
and  integration  of  POSS  actions  and  related  matters  and  would  facilitate 
interaction  with  both  Materiel  Developers  and  Users  of  Intelligence  and  EW 
BFA  BAS.  The  Combat  Developments  Support  Office  would  maintain  contact/ 
liaison  with  the  ERADCOM-managed  PDSS  center  located  at  Fort  Monmouth. 
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(c)  Structure.  The  basic  structure  and  the  relationships 
among  elements  involved  with  this  Objective  PDSS  System,  to  include  an 
illustration  of  the  proposed  way  of  forming  the  CDSF,  are  shown  in  Figure 
2-49.  The  principal  elements  in  this  structure  are  the  same  as  those  shown 
in  Figure  2-47  with  the  exception  of  the  Combat  Developments  Support  Office 
discussed  in  Paragraph  (b),  above.  As  indicated,  permanent  staff  elements 
within  the  proposed  CDSF  would  include  the  proposed  Combat  Developments 
Support  Office  and  the  Simulation  Systems  Management  Office.  The  Combat 
Developments  Support  Office  would  have  primary  responsibility  for  operation 
of  the  CDSF  and  for  coordinating  and  integrating  all  CD  PDSS  activity  at 
USAICS.  The  Simulation  Systems  Management  Office  would  provide  computer 
support  for  the  analyses  and  simulations  conducted  in  the  CDSF,  by  elements 
of  the  Directorate  of  Combat  Developments,  to  examine  PDSS  requirements. 

Other  CDSF  elements  would  be  formed  on  a  task  force  basis  from  existing  USAICS 
staff  organizations  when  and  as  needed  to  provide  a  team  tailored  to  address 
each  major  PDSS  requirement.  The  size  and  composition  of  these  task  force 
teams  would  vary  depending  upon  the  nature  of  the  PDSS  requirement  to  be 
addressed. 


(d)  Operating  concept.  The  concept  of  operations  associated 
with  this  Objective  PDSS  System  at  USAICS  envisions  that  PDSS  will  continue 
to  be  performed  under  the  cognizance  of  the  Director  of  Combat  Developments 
with  participation  by  the  TRADOC  System  Managers  (TSM),  Directorate  of  Train¬ 
ing  Developments,  Computer  Systems  Management  Office,  and  the  US  Army  Intelli¬ 
gence  and  Security  Board,  in  their  respective  areas  of  functional  respon¬ 
sibility.  Within  the  Directorate  of  Combat  Developments,  while  the  focal 
point  for  coordinating  and  integrating  all  PDSS  matters  will  be  the  Combat 
Developments  Support  Office,  primary  responsibility  for  a  PDSS  action  involving 
any  given  BAS  will  normally  rest  with  the  CDSM  for  the  system  being  addressed 
or  impacted.  Other  elements  of  this  directorate,  and  other  elements  of  USAICS 
identified  above,  will  have  major  roles  in  each  PDSS  action  consistent  with 
their  current  functional  responsibilities  as  specified  in  USAICS  Reg.  10-1. 

(e)  Functional  responsibilities.  As  indicated  by  the  dis¬ 
cussion  of  the  concept  of  operations  associated  with  this  Objective  PDSS 
System,  existing  organizational  elements  of  USAICS  would  have  PDSS  respon¬ 
sibilities  consistent  with  and  inherent  in  their  system  development  and  life 
cycle  management  responsibilities  as  currently  assigned  by  USAICS  Reg.  10-1. 

The  responsibilities  of  the  proposed  new  elements  of  the  Objective  PDSS 
structure--the  CDSMs,  the  Combat  Developments  Support  Office,  and  the  CD  PDSS 
Liaison  Office  at  Fort  Monmouth--are  discussed  below.  Specific  functions  of 
both  the  existing  and  proposed  organizational  elements  with  major  respon¬ 
sibilities  in  fulfilling  CD  PDSS  requirements  are  shown  in  Figure  2-50. 
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]_.  Combat  Development  System  Managers.  Each  CDSM  in  the 
Intelligence  and  EW  BFA  will  serve  as  the  software  Combat  Developer  and 
principal  Field  User's  representative  for  PDSS  for  the  system  or  group  of 
systems  for  which  he  is  responsible.  He  manages  and  coordinates  or  performs 
all  software- re la ted  actions  within  the  CD  PDSS  role  for  these  BAS.  He  is 
the  primary  point  of  contact  with  the  MD  on  PDSS  matters  involving  any  of 
these  BAS.  He  coordinates  with  the  Combat  Developments  Support  Office  in 
establishing  priorities  and  in  planning  and  arranging  CDSF  operations  in 
support  of  BAS  for  which  he  is  responsible.  He  interacts  with  the  CD  PDSS 
Liaison  Office  at  Fort  Monmouth  on  matters  involving  PDSS  for  Intelligence 
and  EW  BAS  with  which  he  is  concerned  and  that  are  supported  by  the  ERADCOM- 
managed  PDSS  Center  at  Fort  Monmouth.  Specific  functions  with  which  he  is 
involved  in  either  a  management,  coordination,  or  performance  role  are  shown 
in  Figure  2-50. 


2_.  Combat  Developments  Support  Office.  This  office: 

•  Serves  as  the  focal  point  for  coordinating  and  integrating  all  PDSS 
requirements  and  related  matters  within  USAICS 

t  Plans  and  manages  the  operations  of  the  CDSF  in  supporting  the 
accomplishment  of  all  CD  PDSS  actions  for  BAS  in  the  Intelligence 
and  EW  BFA. 

•  Establishes,  in  coordination  with  affected  CDSMs,  priorities  for 
addressing  PDSS  requirements 

•  Serves  as  the  primary  USAICS  interface  on  PDSS  management  and 
operational  matters  with  the  ERADCOM-managed  PDSS  Centers  at  Fort 
Huachuca  and  Fort  Monmouth 

t  Maintains  technical  expertise  in  Intelligence  and  EW  BAS  and  pro¬ 
vides  a  communications  medium  for  system  software  matters  between 
the  User  and  Materiel  Developer 

•  Serves  as  the  primary  interface  between  elements  of  the  Directorate 
of  Combat  Developments  and  the  Simulation  Systems  Management  Office 
in  planning  and  arranging  automated  support  to  PDSS  analyses 

•  Supervises  the  CD  PDSS  Liaison  Office  at  Fort  Monmouth  which  is 
responsible  for  interfacing  and  coordinating  USAICS  PDSS  require¬ 
ments  with  the  ERADCOM  PDSS  Center  at  that  installation 

•  Arranges,  coordinates,  and  participates  in  visits  to  User  locations 
as  necessary  to  assist  in  identification  and  isolation  of  User 
reported  major  system  problems,  in  developing  functional 
workaround  procedures,  and  in  stating  the  problem  and  CD  require¬ 
ments)  deriving  therefrom  to  the  MD. 
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2-  PDSS  Liaison.  Seven  Category  2  BAS  and  11  Category 
3  BAS  in  the  Intelligence  and  £W  BFA  are  to  be  supported  at  the  PDSS  Center 
operated  by  ERADCOM  at  the  EW  Laboratory,  Fort  Monmouth.  The  Combat  develop¬ 
ments  Support  Office  will  establish  and  maintain  liaison  with  this  ERADCOM 
PDSS  Center  in  connection  with  PDSS  requirements  and  various  related  matters 
involving  software  support  to  these  systems.  This  liaison  effort  will 
facilitate  the  day-to-day  working  level  interaction  that  is  needed  between 
USAICS,  as  the  CD  and  User  representative,  and  ERADCOM  to  ensure  that  CD/User 
requirements  are  adequately  stated  and  understood,  and  that  the  CD  is  aware 
of  MD  capabilities  in  general  and  the  status  of  PDSS  actions  in  particular. 

(f)  Resources.  Estimates  of  the  resources  needed  to  implement 
this  component  of  the  Objective  PDSS  System  at  USAICS  are  presented  below. 

1_.  Personnel.  Time-phased  personnel  resources  estimated 
to  be  needed  are  shown  in  Figure  2-51.  A  breakout  of  these  personnel  by 
organizational  element  is  provided  in  Figure  2-52.  As  discussed  previously 
and  as  indicated  in  these  figures,  the  estimated  resource  requirements  provide 
for  establishing  the  one  new  organizational  element  called  for  by  this  Objec¬ 
tive  System— the  Combat  Developments  Support  Office--and  for  augmenting 
certain  existing  elements  of  USAICS  that  will  be  assuming  added  PDSS  respon¬ 
sibilities  under  the  Objective  PDSS  System.  These  personnel  should  include 
both  military  and  civilian  intelligence  specialists,  operations  research 
analysts,  and  computer  systems  analysts.  This  will  provide  for  the  blend 
of  functional  and  technical  expertise  needed  to  address  CD  PDSS  requirements 
in  this  BFA. 


2.  Facilities.  A  physical  facility  is  needed  to  house 
the  CDSF  to  be  established  under  the  concept  of  this  Objective  PDSS  System. 
Requirements  for  this  facility  include  office  space  for  the  Combat  Develop¬ 
ments  Support  Office  and  elements  of  the  Computer  Systems  Management  Office, 
a  computer  center,  working  space  for  personnel  working  as  members  of  a  task 
force  in  the  CDSF,  and  a  simulation/analysis/test  area  that  would  accommodate 
up  to  10  personnel  working  simultaneously.  It  would  be  desirable  to  collocate 
this  CDSF  with  the  ERADCOM-managed  PDSS  Center  to  be  established  at  Fort 
Huachuca.  If  collocation  is  not  feasible,  other  suitable  space  should  be  pro¬ 
vided  for  the  CDSF  that  will  facilitate  interaction  with  the  PDSS  Center.  It 
is  the  understanding  of  the  Study  Team  that  space  requirements  for  the  Com¬ 
puter  Systems  Management  Office,  referred  to  above,  have  been  separately  deter¬ 
mined  to  be  4000  square  feet.  The  requirement  for  this  space  is  being  addressed 
in  a  phased  plan  which  provides  for  needed  expansion  and  development  of  the 
capabilities  of  the  Computer  Systems  Management  Office.  Excluding  that  re¬ 
quirement,  it  is  estimated  that  an  additional  5000  square  feet  of  space  is 
needed  for  the  remainder  of  the  CDSF,  to  be  used  as  discussed  above. 

3.  Major  items  of  equipment.  Major  items  of  equipment 
have  been  addressed,  in  part,  in  the  plans  for  the  Computer  Systems  Manage¬ 
ment  Office,  referred  to  above.  Other  specific  equipment  needed  must  be 
determined  during  initial  detailed  implementation  planning. 
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USAICS, 

estimated  PERSONNEL  REQUIREMENTS 

PERSONNEL 

FY  81 

FY  82 

FY  83 

FY  84 

FY  85 

FY  86 

FY  87 

Required 

Military 

6 

7 

7 

9 

9 

9 

9 

Civilian 

8 

9 

11 

13 

13 

13 

13 

TOTAL 

14 

16 

18 

22 

22 

22 

22 

Authorized 

Military 

0 

0 

0 

0 

0 

0 

0 

Civilian 

0 

0 

0 

0 

0 

0 

0 

TOTAL 

0 

0 

0 

0 

0 

0 

0 

Additional  Needed 

Military 

6 

7 

7 

9 

9 

9 

9 

Civilian 

8 

9 

11 

13 

13 

13 

13 

TOTAL 

14 

16 

18 

22 

22 

22 

22 

Figure 

2-51.  Estimated  personnel 

requirements,  USAICS 

ELEMENT 

TECHNICAL 

ADMINISTRATIVE 

TOTAL 

MIL 

CIV 

MIL 

CIV 

Combat  Developments  Support  Office 

4 

5 

1 

1 

11 

Augmentation  to: 

ASAS  Management  Office 

1 

0 

0 

0 

1 

Materiel  Division 

•  Corps  Systems  Branch 

1 

1 

0 

0 

2 

•  Division  Systems  Branch 

1 

1 

0 

0 

2 

•  EAC/ Common  Systems  Branch 

0 

1 

0 

0 

1 

•  Test  and 

Evaluation  Office 

0 

1 

0 

0 

1 

Concepts  and  Studies  Division 

•  Systems  Integration 

Branch 

1 

1 

0 

0 

2 

Directorate  of 

Training  Developments 

\  9  New  Systems  Branch, 

DTD 

0 

2 

o 

n 

(  TOTALS 

8 

12 

1 

1 

.  2 r  ! 

Figure  2-52.  Breakout  of  USAICS  personnel  requirements 
by  organizational  element 
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£.  Funds.  An  estimate  of  funds  required  for  the  civilian 
personnel  identified  above  and  the  CDSF  physical  facility  are  shown  in  Figure 
2-53.  Funds  needed  for  equipment  are  dependent  on  requirements  identified 
during  detailed  implementation  planning.  The  civilian  personnel  costs  shown 
are  based  on  an  estimated  average  annual  cost  of  $31. 6K,  including  10  percent 
loading,  for  a  technical-level  civilian  and  $16. OK  for  an  administrative- 
level  civilian. 
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USAICS,  ESTIMATED  PERSONNEL 

COSTS  ($000) 

★ 

FY  81 

FY  82  FY  83 

FY  84 

FY  85 

FY  86 

FY  87 

Development  (RDT&E) 
Procurement  (PA) 
Construction  (MCA) 
Operations  and 
Maintenance  (OMA) 

500.0** 

Civilian 

Personnel 

252.8 

284.4  347.6 

379.6 

379.6 

379.6 

379.6 

TOTAL 

252.8 

284.4  347.6 

879.6 

379.6 

379.6 

379.6 

*In  FY  81  constant 

dollars. 

**  Does  not  include  space  required  ror  tne 
lation  Systems  Management  Office. 

Figure  2-53.  Estimated  personnel  costs,  USAICS 
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h.  Combat  Service  Support  BFA— US  Army  Logistics  Center. 

(1)  General .  Proponency  for  the  Combat  Service  Support  BFA  is 
divided  between  the  US  Army  Logistics  Center  (LOGCEN),  for  logistics  func¬ 
tions,  and  Soldier  Support  Center  (SSC),  for  soldier  support  functions. 
Separate  descriptions  are  provided,  in  this  paragraph  and  in  paragraph  2-5. i., 
of  the  Objective  POSS  System  proposed  for  each  of  these  organizations  for 
providing  PDSS  to  BAS  in  their  respective  portions  of  this  BFA. 

(2)  The  LOGCEN  role  and  mission.  The  LOGCEN  is  designated  by 
TRADOC  Reg.  10-41  as  one  of  three  major  TRADOC  integrating  centers.  It  has 
the  mission  of  ensuring  the  systematic  integration  of  combat  and  training 
developments  functions  in  the  logistics  area.  Included  in  this  broad  mission 
are  the  requirements  for  developing  and  coordinating  the  functional  design, 
installation,  and  maintenance  of  mul ticommand  intermediate  and  user  logistics 
operating/management  information  systems  and  providing  customer  assistance 
for  these  systems.  LOGCEN  organizational  elements  involved  in  performing 
these  system-related  functions,  to  include  POSS,  in  the  Current  System  are 
shown  in  Figure  2-54.  As  indicated  by  the  figure,  these  functions  are  con¬ 
centrated  in  the  Management  Information  Systems  Directorate  and  the  Concepts 
and  Doctrine  Directorate  of  the  LOGCEN.  The  LOGCEN  has  been  involved  for 
many  years  in  performing  CD  PDSS  functions  for  logistics  systems  already 
deployed.  The  projected  deployment  of  new  systems  and  the  further  extension 
of  some  currently  fielded  systems  requires  that  the  current  PDSS  capability 
be  improved.  The  Objective  PDSS  System,  outlined  in  this  report,  has  been 
designed  to  provide  the  needed  enhancement  in  the  LOGCEN' s  current  capability 
with  minimum  change  to  existing  organization  and  operational  procedures. 

(3)  The  current  system. 

(a)  Functional  responsibilities. 

1_.  LOGCEN.  As  the  TRADOC  proponent  for  the  logistics 
portion  of  the  Combat  Service  Support  (CSS)  BFA,  the  LOGCEN  is  responsible, 
among  other  things,  for  the  functional  design  and  development  of  requirements 
for  testing,  validation,  installation  (conversion),  and  maintenance  of  all 
Army  retail  logistics  systems  for  supply  (except  supply  Class  I),  maintenance, 
transportation,  and  ammunition. 

2 .  Management  Information  Systems  Directorate.  Within 
the  LOGCEN,  primary  responsibility  for  the  above  functions  is  assigned  to  the 
Management  Information  Systems  Directorate.  Except  for  the  conceptual  design 
of  certain  systems  for  which  the  Concepts  and  Doctrine  Directorate  is  assigned 
responsibility,  the  Management  Information  Systems  Directorate  is  responsible 
for  developing  and  coordinating  the  functional  plans,  design,  installation, 
maintenance,  and  customer  assistance  of  retail  logistics  operating/management 
information  systems.  Designated  staff  officers  assigned  to  branches  of  the 
Field  Systems  and  Supply  Systems  Divisions,  are  assigned  as  action  officers 
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Figure  2-54.  Organizational  elements  with  major  respon¬ 
sibilities  in  the  current  PDSS  system  for 
the  Logistics  portion  of  the  CSS  BFA 
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for  specific  logistics  systems.  These  personnel  perform  CD  functions  associated 
with  all  phases  of  the  management  information  system  life  cycle.  During  the 
Deployment  and  Operation  Phase  of  the  life  cycle,  they  perform  a  broad  range 
of  PDSS  functions.  These  extend  from  participating  in  customer  assistance 
actions,  through  developing  and  participating  in  the  testing  of  system 
functional  change  requirements,  to  the  installation  of  system  changes  and 
updating  functional  User  procedures  as  required. 

2-  Concepts  and  Doctrine  Directorate.  The  Concepts 
and  Doctrine  Directorate  has  responsibility  for  analysis  and  development  of 
logistics  automation  requirements,  and  for  the  conceptual  design  of  specified 
logistics  systems.  Design  of  the  CSS  Control  System  is  currently  assigned  to 
this  directorate. 

(b)  BAS  to  be  supported.  The  LOGCEN  is  the  TRADOC  proponent 
for  all  logistics  systems  addressed  in  this  study.  These  systems  are  shown 
in  Figure  2-55.  Included  among  these  systems  in  the  CSS  Control  System  for 
which  the  LOGCEN  has  been  tasked  to  take  the  lead  role  in  developing  the  re¬ 
quirements  and  functional  design,  under  the  CCS'1  Concept.  (The  Soldier 
Support  Center  and  Academy  of  Health  Sciences  have  been  tasked  to  develop 
their  respective  inputs  to  this  CCS  Control  System  design  effort.)  The 
LOGCEN1 s  responsibilities  for  these  systems  include  action  associated  with 
all  aspects  of  the  Combat  Developer's  role  in  all  phases  of  the  system  life 
cycle  including  PDSS. 

(4)  The  Objective  System. 

(a)  Purpose.  The  purpose  of  the  Objective  PDSS  System  des¬ 
cribed  in  this  paragraph  is  to  provide  needed  enhancement  of  the  LOGCEN' s 
capability  to  fulfill  its  currently  known  CD  PDSS  responsibilities  associated 
with  the  fielding  of  new  BAS  and  the  further  extension  of  currently  fielded 
BAS  through  the  mid-  to  late-1980s. 

(b)  Principal  features.  The  Objective  PDSS  System  proposed 
for  the  LOGCEN  can  be  characterized  generally  as  an  enhancement  of  the 
existing  structure  and  capability  to  accomplish  PDSS  functions  that  are  the 
responsibility  of  the  CD.  This  is  accomplished  through: 

•  The  establishment  of  a  PDSS  coordination  and  integration  staff 
element  within  the  Management  Support  Division 

•  The  designation  of  a  CDSM  for  each  Logistics  BAS 

•  The  augmentation  of  the  Field  Systems  and  Supply  Systems  Divisions 
of  the  Management  Information  Systems  Directorate  with  additional 
staff  officers  for  handling  PDSS  actions. 


FUNCTIONAL 
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SYSTEM  (BAS) 
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OSU/GSU— DIRECT  SUPPORT  UNIT 
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(OEF INITION/DESIGN) 

LOGCEN/ 

OCSLOG 

SAMS— STANDARD  ARMY  MAIN¬ 
TENANCE  SYSTEM 
(CONCEPT  DEVELOPMENT) 

LOGCEN/ 

OCSLOG 

DLOGS — DIVISION  LOGISTICS 

SYSTEM  (MAINTENANCE) 

LOGCEN/ 
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AND  MANAGEMENT  (OPERATION) 
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(SYSTEM  DEVELOPMENT) 
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LOGCEN/ 
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STANDARD  SUPPLY  SYSTEM 
(SYSTEM  DEVELOPMENT) 

LOGCEN/ 
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R  CCSZ 

LOGCEN/ 

OCSLOG 

OASPS— OA  STANOARO 

PORT  SYSTEM  (OPERATION) 

LOGCEN/ 
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PORT  SYSTEM  ENHANCED 
(SYSTEM  DEVELOPMENT) 

LOGCEN/ 

DCSLOG 

TOPS— TRANSPORTATION 

OPERATIONAL  PERSONNEL 

PROPERTY  STANDARD  SYSTEM 
(SYSTEM  DEVELOPMENT) 

LOGCEN/ 

DCSLOG 

OAMMS— DA  MOVEMENT 

MANAGEMENT  SYSTEM 

SUBSYSTEM  1:  CMM — 

CARGO  MOVEMENT  MODULE 
(SYSTEM  DEVELOPMENT/ 

MAINTENANCE) 

SUBSYSTEM  Z:  MPM— 

movement  planning  module 

(SYSTEM  DEVELOPMENT) 

LOGCEN/ 
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SUPPORT  SYSTEM  (DEPLOYMENT) 
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Figure  2-55.  Logistics  systems 
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(c)  Structure.  A  principal  objective  in  designing  this  pro¬ 
posed  enhancement  to  the  POSS  capability  at  the  LOGCEN  was  that  it  should  re¬ 
quire  minimum  change  to  the  existing  organizational  structure  and  to  the  long¬ 
standing  and  effective  operating  procedures  at  the  LOGCEN.  The  Objective 
System  resulting  from  this  design  effort,  the  elements  of  this  System,  and 
their  relationship  to  the  existing  organizational  structure  are  shown  in  more 
detail  in  Figure  2-56.  The  responsibilities  and  functions  of  each  element 
are  discussed  in  the  following  paragraphs. 

(d)  Functional  responsibilities. 

1_.  CD  POSS  Staff  Element.  This  staff  element  represents 
the  focal  point  for  coordination  of  all  PDSS  requirements  and  activities  at 
the  LOGCEN.  It  is  organized  as  an  element  of  the  Management  Support  Oivision 
in  the  Management  Information  Systems  Directorate.  The  head  of  this  staff 
element  would  serve  as  the  primary  point  of  contact  on  PDSS  matters  with  other 
elements  of  the  LOGCEN,  other  organizations  of  TRADOC,  and  on  administrative 
and  management  matters  with  the  USACSC-managed  PDSS  center  at  Fort  Lee  which 
provides  PDSS  for  all  logistics  systems  addressed  in  this  study.  He  coordi¬ 
nates  PDSS  requirements  and  actions  among  the  operating  elements  of  the 
Management  Information  Systems  Directorate  (MISD)  and  the  Concepts  and 
Doctrine  Directorate.  He  supports  these  organizations  administratively  in 
accomplishing  PDSS  actions  on  systems  for  which  they  are  responsible.  The 
establishment  of  this  PDSS  Staff  Element  will  enable  current  personnel  of 
the  Management  Support  Division  to  concentrate  on  other  essential  functions. 
Specific  functions  of  this  staff  element  are  shown  in  Figure  2-57. 

2.  CDSM  for  each  logistics  system.  At  present,  selected 
staff  officers  within  the  Field  Systems  and  Supply  Systems  Divisions  are 
designated  as  Project  Officers  for  automated  logistics  systems.  In  keeping 
with  the  objective,  stated  above,  of  minimizing  changes  to  current  organi¬ 
zation  and  operating  procedures,  this  Objective  System  provides  for  designa¬ 
ting  these  same  Project  Officers  the  CDSM  for  the  system(s)  for  which  they 
are  currently  responsible.  In  this  role,  these  officers  serve  as  the  CD 
for  PDSS  associated  with  their  respective  system(s).  They  are  responsible 
for  managing  and  performing  or  coordinating  the  performance  of  all  software- 
related  actions  within  the  CD  PDSS  role.  Each  CDSM  is  the  principal  field 
User's  representative  and  the  primary  point  of  contact  with  USACSC  on  PDSS 
matters  affecting  his  system(s).  Specific  functions  for  which  each  CDSM 
is  responsible  in  either  a  management,  coordination,  or  performance  role 
are  shown  in  Figure  2-57. 

2-  PDSS  staff  augmentation  to  the  Field  Systems  and 
Supply  Systems  Divisions.  This  Objective  System  provides  that  CD  PDSS 
actions  will  continue  to  be  accomplished  by  system  personnel  in  each  of 
these  MISD  divisions,  as  they  are  at  the  present  time,  under  the  control  and 
supervision  of  the  CDSM  for  each  system.  To  provide  an  improved  capability 
to  handle  the  increased  PDSS  requirements  associated  with  new  systems  pro¬ 
jected  for  fielding  and  systems  currently  fielded  but  being  extended  to 
additional  users,  this  Objective  System  provides  for  a  personnel  augmenta- 
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tion  to  each  operating  division  of  MISD.  It  is  envisioned  that  these  personnel 
would  be  integrated  into  the  existing  branch  structure  of  these  divisions 
and  assigned  responsibility  for  POSS  functions.  The  functions  to  be  performed 
are  shown  in  Figure  2-57. 

4.  Concepts  and  Doctrine  Directorate.  No  requirement 
for  a  personnel  augmentation  to  the  Concepts  and  Doctrine  Directorate  for 
handling  PDSS  actions  is  foreseen  or  provided  for  in  this  System.  Except 
for  PDSS  planning  during  system  design,  it  is  assumed  that  PDSS  for  all 
systems  will  be  the  responsibility  of  MISD. 

(e)  Resources.  Time-phased  estimates  of  resources  needed  to 
establish  this  Objective  PDSS  System  component  for  support  of  the  logistics 
portion  of  the  CSS  BFA  are  discussed  below. 

1_.  Personnel.  Personnel  needed  in  addition  to  current 
authorizations  are  shown  in  Figure  2-5S.  A  breakout  of  these  additional 
personnel  requirements  by  organizational  element  is  shown  in  Figure  2-59. 

2.  Facilities.  Physical  facility  requirements  include 
office  space  for  the  CD  PDSS  Staff  element  and  the  PDSS  personnel  augmenta¬ 
tions  to  the  Supply  Systems  and  Field  Systems  Divisions.  This  space  should 
be  made  available  within  the  current  MISD  area. 

2-  Major  equipment.  A  terminal  is  needed  to  the  TRADOC 
Data  Processing  Field  Office  computer  at  Fort  Leavenworth  to  facilitate  inter¬ 
action  with  CACDA  in  designing,  managing,  and  exercising  configuration  control 
over  the  major  command  and  control  BAS  under  the  CCS^  Concept.  Specific 
equipment  requirements  must  be  identified  during  detailed  implementation 
planning. 


£.  Funds.  An  estimate  of  funds  required  for  the 
additional  civilian  personnel  requirements  identified  above  is  shown  in 
Figure  2-60.  This  estimate  is  in  FY  81  constant  dollars  and  is  based  on 
an  average  annual  cost  of  $31. 6K  including  10  percent  loading,  for  tech¬ 
nical-level  civilian  personnel. 
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LOGCEN, 

ESTIMATED 

PERSONNEL  REQUIREMENTS 

PERSONNEL 

FY  81 

FY  82 

FY  83 

FY  84 

FY  85 

FY  86 

FY  87 

Required 

Military 

3 

3 

4 

6 

6 

7 

7 

Civilian 

6 

6 

7 

11 

11 

12 

12 

TOTAL 

9 

9 

11 

17 

17 

19 

19 

Authorized 

Military 

0 

0 

0 

0 

0 

0 

0 

Civilian 

0 

0 

0 

0 

0 

0 

0 

TOTAL 

0 

0 

0 

0 

0 

0 

0 

Additional 

Military 

Needed 

3 

3 

4 

6 

6 

7 

7 

Civilian 

6 

6 

7 

11 

11 

12 

12 

TOTAL 

9 

9 

11 

17 

17 

19 

19 

Figure  2-58.  Personnel  requirements,  LOGCEN 


ELEMENT 

TECHNICAL 

MIL  CIV 

ADMINISTRATIVE 
MIL  CIV 

TOTAL 

CD  PDSS  Staff  Element 

1 

2 

0 

0 

3 

Field  Systems  Division 

4 

6 

0 

0 

10 

Supply  Systems  Division 

2 

4 

0 

0 

6 

TOTALS 

7 

12 

0 

0 

19 

Figure  2-59.  Breakout  of  LOGCEN  personnel  requirements 
by  organizational  element 


LOGCEN,  ESTIMATED  PERSONNEL  COSTS  ($000)* 

FY  81  FY  82  FY  83  FY  84  FY  85  FY  86  FY  87 

Civilian  Personnel! 189.6  189.6  221.2  347.6  347.6  379.2  379.2 

*  In  FY  81  constant  dollars. 

Figure  2-60.  Estimated  personnel  costs,  LOGCEN 
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i .  Combat  Service  Support  BFA-Soldier  Support  Center. 

(1 )  General . 

(a)  US  Army  Soldier  Support  Center  Mission.  TRADOC  Reg.  10-41 
which  is  based  on  AR  10-41,  designates  the  US  Army  Soldier  Support  Center 
(SSC)  as  one  of  three  major  TRADOC  integrating  centers  with  responsibility  to 
ensure  the  systematic  integration  of  combat  and  training  developments  func¬ 
tions  in  the  soldier  support  operational  area.  With  respect  to  automated 
systems,  this  TRADOC  Reg.  assigns  SSC  the  mission  to  develop  and  coordinate 
the  functional  design,  evaluation,  and  extension  of  battlefield  administra¬ 
tion  management  information  systems  applicable  to  the  corps  level  and  below. 
This  TRADOC  Reg.  further  states  that  the  TRADOC  integrating  center  commanders 
are  authorized  and  required  to  task  and  provide  guidance  to  other  Army 
commands  and  agencies  having  combat  developments  functions  assigned  by  HQDA 
and  to  integrate  the  resultant  products  into  the  overall  combat  and  training 
development  effort. 

(b)  US  Army  Mil itary  Personnel  Center.  AR  10-5  assigns  the 
Deputy  Chief  of  Staff  for  Personnel  (DCSPER)  general  staff  responsibility 
for  automated  management  information  systems  in  support  of  all  assigned 
functional  areas  of  responsibility.  Included  is  responsibility  for  developing 
personnel  systems  to  meet  the  needs  of  new  or  improved  doctrine,  organization, 
and  materiel.  The  US  Army  Military  Personnel  Center  (MILPERCEN),  a  field 
operating  agency  of  the  DCSPER,  performs  the  functions  necessary  to  enable 
the  DCSPER  to  fulfill  these  responsibilities.  Based  on  this  assignment  of 
responsibility,  MILPERCEN  has  been  functioning  as  the  Combat  Developer  for 
most  personnel  support  systems. 

(c)  DCSPER-TRADOC  Memorandum  of  Understanding.  On  5-7  August 
1980,  a  memorandum  of  understanding  (MOU)  was  signed  by  the  DCSPER  and  the 
Commanders  of  TRADOC,  MILPERCEN,  and  SSC.  This  MOU  was  intended  to  clarify, 
define,  and  realign  certain  functional  responsibilities  and  boundaries  between 
MILPERCEN  and  Soldier  Support  Center.  Portions  of  this  MOU  are  relevant  to 
responsibilities  for  the  development  and  support  of  personnel  and  administra¬ 
tive  information  systems.  This  MOU  is  discussed  in  considerable  detail  in 
Paragraph  2-4., f..  Volume  II,  First  Interim  Technical  Report  of  the  Assessment 
of  the  Combat  Developer's  Role  in  Post  Deployment  Software  Support.  Since 

no  formal  changes  have  occurred  since  publication  of  that  report,  that  discus¬ 
sion  will  not  be  repeated  here.  However,  it  should  be  noted  that  while  this 
MOU  is  a  major  step  toward  realization  of  the  intended  goal,  some  questions 
remain  regarding  the  division  of  responsibilities  between  MILPERCEN  and  SSC 
in  this  important  functional  area.  As  a  result,  the  role  exercised  by  SSC 
in  system  development  and  life  cycle  management,  to  include  PDSS,  is  not  as 
clearly  defined  as  it  should  be  and  appears  to  be  more  limited  than  that  of 
other  TRADOC  integrating  and  functional  centers.  The  current  capability  that 
exists  at  SSC  to  fulfill  the  PDSS  role  presently  identified  is  discussed  in 
Paragraph  (2),  below.  The  Objective  PDSS  System,  which  provides  for  needed 
improvement  in  this  current  capability,  is  discussed  in  Paragraph  (3). 


i^k.  bJuAUK-NOi  nuiu 
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(2)  The  Current  System.  The  Current  System  for  providing  PDSS  to 
automated  systems  in  the  soldier  support  portion  of  the  CSS  BFA  has  its  focal 
point  in  the  Management  Information  Systems  Division  (MISD)  in  the  Directorate 
of  Doctrine  and  Combat  Development  (DDCD),  of  the  US  Army  Institute  of 
Personnel  and  Resource  Management,  SSC.  The  Directorate  of  Training  Develop¬ 
ments  of  that  Institute  is  also  involved,  secondarily,  in  the  current  PDSS 
System,  as  are  certain  TRADOC  elements  at  other  installations.  Outside  of 
TRADOC,  elements  of  the  Deputy  Chief  of  Staff  for  Personnel  (DCSPER),  MILPERCEN, 
the  Computer  Systems  Command,  Health  Services  Command,  and  Users,  are  also 
involved.  Figure  2-61  shows  the  organizational  structure  of  the  elements  of 
this  system  at  SSC.  Figure  2-62  shows,  in  less  detail,  the  structure  of  the 
total  TRADOC  PDSS  System  for  the  personnel  portion  of  the  CSS  BFA. 

(a)  Functional  responsibilities.  Principal  PDSS  respon¬ 
sibilities  within  SSC  fall  within  the  MISD  and  other  elements  of  the  DDCD, 
identified  in  Figure  2-61,  above.  Responsibility  for  training  materials 
pertaining  to  PDSS  falls  within  the  Directorate  of  Training  Development, 
although  no  relevant  BAS  has  reached  a  stage  where  such  responsibility  has 
needed  to  be  exercised,  since  MILPERCEN  has  exercised  responsibility  over 
the  Standard  Installation  Division  Personnel  System  (SIDPERS). 

(b)  BAS  addressed.  In  the  First  Interim  Technical  Report  of 
this  study  effort,  ten  BAS  or  related  categories  of  activity  were  identified 
that  could  be  anticipated  to  require  some  degree  of  PDSS  in  this  portion  of 
the  CSS  BFA.  Because  many  of  those  ten  are  seen  primarily  to  involve  monitor¬ 
ing  or  coordination  responsibilities  by  SSC,  that  list  of  ten  has  been  con¬ 
solidated  into  five  categories.  Of  these  five,  one  is  a  specific  BAS  which 
will  require  significant  PDSS,  the  New  Personnel  System  or  PERMIS.  Another 
one  of  the  five  which  may  present  a  significant  PDSS  requirement  is  the 
Personnel  Support  Subsystem  for  the  CSS  Control  System  being  developed  under 
the  Command,  Control  and  Subordinate  Systems  (CCS*)  concept.  Of  the  remaining 
three  categories,  only  Software  Conversion  for  New  Hardware,  which  is  in  the 
post-deployment  phase,  appears  to  present  a  significant,  current  PDSS  re¬ 
quirement  (and  MILPERCEN  has  retained  control  of  that  effort  thus  far). 

These  five  categories  are  identified  in  Figure  2-63. 

(c)  Principal  interfaces.  Figures  2-61  and  2-62,  above, 
identified  the  TRADOC  elements  involved  in  the  current  PDSS  System  for  the 
SSC  portion  of  the  CSS  BFA.  Figure  2-64  combines  that  TRADOC  structure  with  a 
summary  identification  of  the  non-TRADOC  elements  involved.  Although  PDSS 
interfaces  of  some  sort  will  exist  among  most  of  these  elements,  those  inter¬ 
faces, through  which  the  major  TRADOC  portions  of  the  volume  of  PDSS  transac¬ 
tions  pass  in  the  Current  PDSS  System,  center  around  the  MISD  of  the  DDCD  at 
SSC.  Such  principal  interfaces  are  indicated  in  Figure  2-65. 
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Figure  2-61.  TRADOC  elements  of  the  current  PDSS  System  at  SSC 
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Figure  2-62.  Overall  TRADOC  elements  of  the  current  PDSS  systeri 
for  Personnel  portion  of  CSS  BFA 
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BATTLEFIELD  AUTOMATED  SYSTEM  (BAS) 
AND  STAGE  IN  LIFE  CYCLE 


1.  SOFTWARE  CONVERSION  FOR  NEW  HARDWARE  (DAS3,  ETC.) 
(POST-DEPLOYMENT) 

2.  PERSONNEL  SUPPORT  SUBSYSTEM  FOR  THE  CSS  CONTROL  SYSTEM  FOR 
CCS2  (CONCEPTUAL) 

3.  NEW  PERSONNEL  SYSTEM  (PERSONNEL  MANAGEMENT  INFORMATION 
SYSTEM  (PERMIS) )  (CONCEPTUAL) 

4.  INTERFACES  WITH  TAMMIS 
(CONCEPTUAL) 

5.  OTHER*  (POST-DEPLOYMENT  THROUGH  EARLY  CONCEPTUAL) 


*  PRIMARILY  MONITORING,  OVERSIGHT,  COORDINATION.  SYSTEMS 
INCLUDED  ARE:  SIOPERS  AND  SIDPERS  WARTIME  AND  A  RELATED 
PERSONNEL  SOFTWARE  PACKAGE  FOR  DLDED;  PWIS;  VFDMIS;  OESS; 
TAPER  AND  TAPER  WARTIME;  AND  VTAADS.  FOR  ADDITIONAL 
DETAILS,  REFERENCE  MAY  BE  MADE  TO  FIRST  INTERIM  TECHNICAL 
REPORT,  PP.  2-53  THROUGH  2-55,  AND  3-30  THROUGH  3-31. 


Figure  2-63.  Systems  requiring  PDSS--So1dier  Support  Center 
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Figure  2-64.  Principal  TRADOC  and  other  elements  in  the 
current  PDSS  system  for  Personnel  portion 
of  CSS  BFA 
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(3)  The  Objective  System. 

(a)  Purpose.  The  purpose  of  this  component  of  the  proposed 
TRADOC  POSS  Objective  System  is  to  provide  the  SSC  an  improved  capability  to 
perform  CD  PDSS  functions  for  which  it  is  responsible  based  on  projected  re¬ 
quirements  through  the  mid-  to  late-1980s.  This  component  of  the  Objective 
PDSS  System  has  been  designed  based  on  the  assumption  that  there  will  be  no 
changes  in  system  proponency  and  no  further  transfer  of  PDSS-related  func¬ 
tions  or  associated  resources  between  MILPERCEN  and  SSC. 

(b)  Principal  features.  This  component  of  the  Objective  PDSS 
System  can  be  characterized  as  an  augmentation  to  the  Management  Information 
Systems  Division,  Directorate  of  Doctrine  and  Combat  Developments,  to  provide 
an  improved  capability  for  handling  current  and  projected  PDSS  requirements. 
This  augmentation  is  achieved  through  the  establishment  of  a  PDSS  Team  in  the 
MISD  to  serve  as  the  focal  point  and  principal  action  element  for  PDSS  and 
related  activities.  The  Chief  of  the  PDSS  Team  would  also  be  designated  the 
Assistant  CDSM  for  Personnel  Systems.  The  Chief,  MISD  would  be  designated 
the  CDSM,  Personnel  Systems. 

(c)  Structure.  The  structure  of  organizational  elements  at 
SSC  involved  with  PDSS  in  this  Objective  PDSS  System  are  shown  in  Figure  2-66. 
The  focal  point  for  PDSS  activity  will  be  the  proposed  PDSS  Team,  discussed 
above.  This  PDSS  Team  is  shown  as  one  of  four  principal  teams  under  MISD.  The 
CDSM  and  Assistant  CDSM  for  Personnel  Systems  are  also  shown.  The  composition 
of  the  PDSS  Team  includes: 

•  The  Team  Chief 

t  A  Systems  Action  Element  including  representatives  or  action  officers 
for: 

•e  CCS2 
••  PERMIS 
••  Other  Systems. 

•  A  Facility  Support  Action  Officer 

•  A  PDSS  Liaison  Officer  to  coordinate  PDSS  activity  with  MILPERCEN 
and  USACSC. 

(d)  Operating  concept.  Under  the  concept  of  operations  associ¬ 
ated  with  this  component  of  the  Objective  PDSS  System,  the  PDSS  Team  at  the 
SSC  will  function  as  the  focal  point  for  fulfilling  TRADOC  responsibilities 
for  all  PDSS-related  actions  involving  the  systems  or  groups  of  systems 
listed  in  Figure  2-63.  This  PDSS  Team  would  interface  with  and,  as  appro- 
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priate,  coordinate  and  integrate  the  activities  of  other  SSC  elements,  other 
TRADOC  organizations,  and  Army  organizations  external  to  TRADOC  that  are 
involved  with  PDSS  for  these  systems.  The  principal  elements  and  interfaces 
involved  in  this  operational  concept  are  shown  in  Figure  2-67. 

(e)  Functional  responsibilities.  The  overall  responsibility 
of  the  CDSM,  Personnel  Systems  and  the  SSC  PDSS  Team  is  to  ensure  that  all  CD 
PDSS  requirements  pertaining  to  the  soldier  support  portion  of  the  CSS  BFA 
which  are  assigned  to  the  SSC  are  adequately  fulfilled.  Specific  respon¬ 
sibilities  and  functions  of  the  elements  of  the  PDSS  Team  are  outlined  below. 

1_.  CDSM,  Personnel  System.  The  CDSM,  Personnel  Systems, 
is  responsible  for  all  substantive  CD  PDSS  actions  for  BAS  for  which  the 
Soldier  Support  Center  is  assigned  responsibility.  Because  of  the  currently 
limited  nature  of  these  responsibilities,  the  Chief,  MIS  Division,  is  design¬ 
ated  as  CDSM,  Personnel  Systems,  as  an  additional  duty.  He  is  assisted  in 
all  substantive  PDSS  actions  by  the  Chief  of  the  PDSS  Team  who  serves  as 
the  Assistant  CDSM. 


2.  Chief,  PDSS  Team  and  Assistant  CDSM,  Personnel  Systems. 
The  Chief,  PDSS  Team  is  the  principal  administrator  of  PDSS  functions  at  the 
Soldier  Support  Center.  He  reports  to  the  Chief,  MIS  Division.  He  is 
responsible  for  planning  and  directing  operations  of  the  PDSS  Team  in  close 
coordination  with  other  SSC,  TRADOC,  and  Army  organizations  with  which  the 
PDSS  Team  interfaces.  As  stated  above,  the  Chief,  PDSS  Team,  is  also  design¬ 
ated  the  Assistant  CDSM,  Personnel  Systems.  In  this  capability,  he  assists 
the  CDSM,  Personnel  Systems,  in  fulfilling  responsibilities  as  the  CD  for 

PDSS  actions  affecting  systems  for  which  the  SSC  has  proponency. 

3.  Systems  Action  Element  of  the  PDSS  Team.  This  element 
consists  of  representatives  or  action  officers  who  provide  the  focal  point  for 
actions  involving  the  BAS  or  groups  of  BAS  shown  in  Figure  2-63.  Respon¬ 
sibilities  are  described  below. 

2 

a_.  CCS  Subsystem  Action  Officer.  This  action 
officer  is  involved  with  PDSS  aspects  of  the  Personnel  Subsystem  of  the  CSS 
Control  System  being  designed  and  developed  under  the  CCS^  Concept.  The  US 
Army  LOGCEN  has  been  assigned  the  lead  role  in  the  development  of  the  CSS 
Control  System  with  participation  and  appropriate  input  from  both  SSC  and 
the  Academy  of  Health  Sciences. 

b.  New  Personnel  System  (PERMIS)  Action  Officer. 

This  action  officer  is  involved  with  PDSS  aspects  of  PERMIS,  a  system  being 
designed  to  replace  SIDPERS.  PERMIS  will  interface  with  the  Theater  Army 
Medical  Management  Information  System  (TAMMIS)  which  is  in  the  conceptual 
stage. 
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Figure  2-67  Principal  elements  and  interfaces  involved 
in  the  Objective  PDSS  System  for  SSC 
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c_.  Other  Systems  Action  Officer.  This  action  officer 
is  involved  with  monitoring  and  coordinating  responsibilities  pertaining  to 
several  BAS,  including  SIDPERS,  SIDPERS  Wartime,  a  Personnel  Software  Package 
for  DLDED,  the  Prisoners  of  War  Information  System  (PWIS),  the  Vertical  Force 
Development  Information  System  (VFDMIS)  Theater  Army  Personnel  Rollup  (TAPER) 
and  TAPER  Wartime,  Vertical  The  Army  Authorization  Documents  System  (VTAADS), 
and  OESS.  It  should  be  noted  that  under  provisions  of  the  MOU  discussed  in 
Paragraph  2-5.i.(l),  the  SSC  is  responsible  for  all  changes  to  SIDPERS  soft¬ 
ware  which  are  anticipated  to  cost  over  $  1 OOK .  The  small  PDSS  Team  proposed 
for  the  SSC  in  this  Objective  PDSS  System  does  not  provide  a  capability  to 
handle  actions  of  such  a  magnitude.  There  have  been  no  such  requirements  to 
date.  The  way  they  would  be  handled,  should  they  occur,  is  a  subject  area 
that  must  be  addressed  further. 

4.  Facility  Support  Action  Officers.  The  Facility 
Support  Action  Officer  is  responsible  for  anticipating  and  planning  for 
meeting  the  facility,  equipment,  and  related  support  needs  of  the  PDSS  Team, 
including  any  needs  that  may  arise  for  computer  support,  modeling,  simulation, 
testing,  and  analysis  of  BAS  software.  This  action  officer  will  also  support 
or  effect  support  of  any  special  communications  capabilities  needed  by  the 
PDSS  Team. 


5..  CD  PDSS  Liaison  Office.  This  office,  located 
with  the  SSC,  National  Capital  Region,  will  provide  liaison  to  both  the 
MILPERCEN  and  USACSC  on  PDSS  and  related  matters  involving  systems  with  which 
SSC  is  involved. 

(f)  Resources.  An  estimate  of  personnel  resources  needed  to 
implement  the  Objective  PDSS  System  at  the  SSC  is  shown  in  Figure  2-68.  A 
breakout  of  these  resources  by  organizational  element  is  provided  in  Figure 
2-69.  An  estimate  of  the  costs  for  these  personnel  and  a  limited  amount  of 
TDY  expenses  is  presented  in  Figure  2-70.  The  personnel  costs  shown  are 
based  on  an  average  annual  cost  of  $31. 6K  for  each  managerial/technical 
level  civilian,  including  10  percent  loading. 
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SSC, 

PDSS  TEAM, 

ESTIMATED 

PERSONNEL  REQUIREMENTS 

PERSONNEL 

FY  81 

FY  82 

FY  83 

FY  84 

FY  85 

FY  86 

FY  87 

Required 

Military 

3 

3 

3 

4 

4 

4 

4 

Civilian 

0 

0 

0 

2 

2 

2 

2 

TOTAL 

3 

3 

3 

6 

6 

6 

6 

Authorized 

Military 

3 

3 

3 

6 

6 

6 

6 

Civilian 

0 

0 

0 

0 

0 

0 

0 

TOTAL 

3 

3 

3 

6 

6 

6 

6 

Additional 

Military 

Needed 

0 

0 

0 

-2 

-2 

-2 

-2 

Civilian 

0 

0 

0 

2 

2 

2 

2 

TOTAL 

0 

0 

0 

0 

0 

0 

0 

Figure  2-68.  Personnel  requirements,  SSC 


ELEMENT 


Chief,  PDSS  Team  and  Assistant  CDSM 

CCS2  Subsystem 

PERMIS 

Other  Systems 
Facility  Support 
CD  PDSS  LNO 
TOTAL 


MANAGERIAL 

CLERICAL 

AND 

TECHNICAL 

AND 

TECHNICIANS 

TOTAL 

MIL 

CIV 

MIL 

CIV 

** 

■ 

1 

0 

0 

0 

1 

1 

0 

0 

0 

1 

1 

0 

0 

0 

1 

0 

1 

0 

0 

1 

0 

1 

0 

0 

1 

1 

0 

0 

0 

1 

T 

T 

0 

0 

6 

Figure  2-69.  Breakout  of  personnel  requirements 
by  organizational  element 
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SSC,  ESTIMATED  PERSONNEL  COSTS  ($000)* 

FY  81 

FY  82  FY  83  FY  84  FY  85 

FY  86 

FY  87 

Development, (RDT&E) 
Procurement  (PA) 
Construction  (MCA) 
Operations  and 
Maintenance  (OMA) 

Civilian 

Salaries 

63.2  63.2 

63.2 

63.2 

TDY 

12 

12  30  61  43 

34 

34 

TOTAL 

12 

12  30  123.2  106.2 

97.2 

97.2 

*  In  FY  81  constant 

dollars. 

Figure  2-70.  Estimate  of  funding  required,  SSC 
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j.  Summary.  The  proposed  Objective  PDSS  System  described  in  the 
previous  paragraphs  would,  if  implemented,  provide  TRADOC  a  capability 
adequate  to  accomplish  currently  identified  PDSS  requirements  through  the 
mid-  to  late-1980s.  The  system  described  should  be  regarded  as  a  blueprint 
which  may  be  modified,  within  the  constraints  and  guidelines  presented  in 
Paragraph  2-2,  as  PDSS  requirements  and  other  driving  factors  change  prior 
to  or  during  the  course  of  implementation.  The  description  of  the  Objective 
PDSS  System  and  the  proposed  Implementation  Plan  contained  in  this  report 
provide  the  basis  for  proceeding  with  detailed  planning  for  each  component 
of  the  system.  Further  component  planning  must  address  and  refine  or 
develop  details  of  resource  requirements  in  the  areas  of  personnel,  physical 
facilities,  equipment,  and  funding  needed  to  implement  the  system.  Each 
of  these  areas  has  been  addressed  to  some  extent  for  each  system  component, 
but  further  refinement  is  needed  based  on  detailed  planning  at  the  center  and 
school  level.  With  respect  to  personnel  requirements,  estimates  for  each 
major  system  component  were  presented  in  the  previous  paragraphs.  Figure 
2-71  provides  a  summary  of  the  total  requirements  for  TRADOC  from  FY  81 
through  FY  87. 
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Figure  2-71.  Estimated  TRADOC  PDSS  personnel  requirements  by  fiscal  year 
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CHAPTER  3 

OBJECTIVE  SYSTEM  IMPLEMENTATION 

3-1  GENERAL.  Task  8  of  the  Statement  of  Work  of  the  contract  under  which 
this  study  is  being  conducted  specifies  that  an  implementation  plan  is  to 
be  developed  that  will  provide  for  transition  from  the  present  situation 
to  a  TRADOC-selected  PDSS  model  or  system.  The  Objective  PDSS  System  des¬ 
cribed  in  Chapter  2  represents  the  "selected"  TRADOC  model  or  system  to  be 
implemented  although  it  may  undergo  some  further  revision  during  subsequent 
TRADOC  review.  This  chapter  addresses  the  plan  for  implementation  of  the 
Objective  PDSS  System  as  required  by  the  statement  of  work. 

3-2.  THE  PROPOSED  IMPLEMENTATION  PLAN. 

a.  Structure  of  the  Plan.  A  proposed  implementation  plan,  to  be 
staffed,  approved,  and  issued  by  HQ  TRADOC,  has  been  prepared  and  is  included 
as  Appendix  D  of  this  Third  Interim  Technical  Report.  This  proposed  plan 
consists  of  the  following: 

•  Essential  introductory  and  administrative  material  to  include: 

••  The  origin  of  the  PDSS  mission 

••  The  purpose,  scope,  authority,  and  applicability  of  the  plan 
••  Identification  of  key  references 
at  Assumptions  on  which  the  plan  is  based. 

•  Responsibilities  for  executing  the  plan 

a  Coordination  authority  and  requirements 

•  Principal  actions  to  be  accomplished  in  executing  the  plan 

•  A  discussion  of  the  implementation  schedule 

•  Reporting  requirements 

•  Three  annexes  for  inclusion  of: 

••  A  listing  of  key  references 

aa  A  description  of  the  TRADOC  Objective  PDSS  System  (essentially 
as  presented  in  Chapter  2  of  this  report) 

••  A  tabular  arrangement  of  the  principal  actions  to  be  accom¬ 
plished,  to  facilitate  use  of  this  information  by  all 
TRADOC  elements  involved  with  the  execution  of  the  plan. 


3-2 


b.  The  Proposed  Implementation  Schedule. 

(1)  Time  period  addressed.  The  proposed  implementation  plan  in 
Appendix  D  covers  those  principal  actions  or  events  that  need  to  be  accom¬ 
plished  during  the  initial  (approximately  one  year)  period  of  this  TRADOC 
implementation  effort,  from  March  1981  through  March  1982.  If  this  schedule 
is  maintained,  other  actions  originating  from  these  initial  actions  will 
then  continue  on  for  several  years  before  full  implementation  is  achieved. 
Throughout  this  implementation  period  and  beyond,  a  number  of  actions  associ¬ 
ated  with  the  TRADOC  Resources  Management  System  (TRADOC  Pam.  11-11)  and  the 
Priorities  and  Tasking  Control  Process  (TRADOC  Reg.  11-2)  must  be  accomplished 
on  a  recurring  basis. 

(2)  Critical  aspects  of  the  schedule.  In  the  interest  of  pro¬ 
ceeding  with  implementation  expeditiously,  a  very  compressed  schedule  has 
been  proposed  for  the  execution  of  this  plan.  For  example,  it  provides  for 
the  accomplishment  of  special  actions  directed  toward  the  inclusion  of  criti¬ 
cal  PDSS  resource  requirements  in  the  FY  83  TRADOC  Command  Budget  Estimate 
(CBE).  If  these  actions  are  not  taken,  a  delay  of  one  year  may  be  experienced 
in  getting  PDSS  requirements  into  the  programming  and  budgeting  process. 
However,  to  meet  the  schedule  that  is  proposed,  some  actions  must  be  initiat¬ 
ed  immediately  upon  receipt  of  the  final  report  of  this  current  TRADOC  PDSS 
Study.  These  early  actions  would  have  to  precede  the  finalization  and 
issuance  of  this  implementation  plan.  Therefore,  the  complete  set  of  princi¬ 
pal  actions  that  need  to  be  accomplished  to  effect  implementation  have  been 
divided  into  two  groups  or  phases.  Those  actions  that  should  be  accomplished 
or  at  least  initated  prior  to  the  time  that  this  implementation  plan  can  be 
completed  and  issued  constitute  Phase  I.  Those  that  are  to  be  initiated 
following  issuance  of  this  plan  constitute  Phase  II.  Phase  I  actions  would 
proceed  based  on  verbal  authority  of  the  Commander,  TRADOC.  The  approved 
implementation  plan  would  be  authority  for  continuing  with  the  Phase  II 
actions.  To  provide  a  complete  picture  of  the  implementation  effort,  the 
total  set  of  implementation  actions  (both  Phases  I  and  II)  are  included  in 
the  preposed  plan  at  Appendix  D. 

3-3.  ACTIONS  REQUIRED  TO  FINALIZE  THE  PLAN.  The  proposed  implementation 
plan,  as  presented  in  Appendix  D,  is  essentially  complete  except  for 
inclusion  of  the  final  version  of  the  description  of  the  TRADOC  Objective 
PDSS  System  (as  Annex  II  to  the  plan)  and  making  any  other  modifications 
determined  during  TRADOC  review  to  be  needed  (e.g.,  changes  to  the  set  of 
actions  or  schedule).  The  proposed  schedule  provides  for  the  plan  to  be 
revised  following  formal  TRADOC  review  (expected  to  be  in  late  March  or 
early  April),  staffed,  published,  and  distributed  in  late  August  or  early 
September  1981. 
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APPENDIX  A 
REFERENCE  APPENDIX 


1.  Integrated  Tactical  Communications  System  Plan  (INTACS).  1978. 

2.  US  Department  of  the  Army.  Headquarters,  US  Army  Materiel  Development  and 

Readiness  Command.  Post-Deployment  Software  Support  Plan  for 
Intel! igence/Electronic  Warfare  (INTEL/EW)  Systems.  8  March  1978. 

3.  _ .  Post-Deployment  Software  Support  (POSS)  Concept  Plan  for 

Battlefield  Automated  Systems.  Washington  D.C.:  May  1980. 

4.  Post-Deployment  Management  Plan  for  Fire  Direction  System  Artillery 

AN/GS6- 1 0( V ) .  ( TACFtRE )  Draft .  6  December  1976 . 

5.  International  Business  Machines  Corporation,  Federal  Systems  Division. 

Army  Command  and  Control  Master  Plan  (AC^MP)  effort,  published 
under  various  titles.  Arlington:  1  June  1979. 

6.  ADCCS  Directorate  and  ARTADS.  AN/TSQ-73  (Missile  Minder)  Post-Deploy¬ 

ment  Management  Plan.  Huntsville  and  Fort  Monmouth:  19  May  1977. 

7.  US  Department  of  the  Army.  Headquarters,  Combined  Arms  Center  and 

Fort  Leavenworth.  Position  Location  Reporting  System  (PLRS) 
Post-Deployment  Support  Concepts  Presentation.  Fort  Leavenworth: 
11  March  1977. 

8.  _ .  Battlefield  Automation  Management  Program  (BAMP).  Fort 

Leavenworth:  1  July  1978. 

9.  _ .  US  Army  Combined  Arms  Combat  Development  Activity.  Functional 

Systems  on  the  Corps  Battlefield.  US  Army  Combined  Arms  Center. 
Fort  Leavenworth:  13  July  1978. 

10.  _ .  Mission  Element  Needs  Statement  (MENS)  for  the  Military 

Computer  Family  (MCF).  Fort  Leavenworth:  September  1978. 

11.  Joint  Chairmen,  Communications  Research  and  Development  Command  and 

Center  for  Systems  Engineering  and  Integration.  Army  Battlefield 
Automation  Interoperabil ity  System  Engineering  Management  PfarT 
Working  Group.  Fort  Monmouth:  31  January  197$. 


A-2 


12.  US  Department  of  the  Army.  Army  Battlefield  Interface  Concept  80  (U) 

(Short  Title:  ABIC  80).  Draft.  ACN  Number  47635.  Washington, 
D.C.  (CONFIDENTIAL) 

13.  CORADCOM.  Guidance  on  Preparing  a  Product  Improvement  Proposal.  Fort 

Monmouth:  January  1978. 

14.  Report  of  the  Defense  Science  Board  Task  Force  on  Command  and  Control 

Systems  Management!  July  1978. 

15.  PATRIOT  Software  Support  Facility  Plan.  July  1978. 

16.  Joint  Interoperability  Tactical  Command  and  Control  Systems  (JINTACCS) 

reports,  published  under  various  titles. 

17.  US  Department  of  Defense.  Department  of  Defense  Directive  5010.19: 

Configuration  Management.  Washington,  D.C. :  T"  May  1979. 

18.  _ .  Department  of  Defense  Instructions  5010.27:  Management  of 

Automated  Data  System  Development.  Washington,  D.C. 

19.  _ .  Department  of  Defense  Directive  5000.29:  Management  of 

Computer  Resources  in  Major  Defense  Systems.  Washington,  D.C.: 

26  April  1976. 

20.  .  Department  of  Defense  Directive  5000.31:  Interim  List  of 

DOD  -  Approved  High  Order  Programming  Languages  (HOL). 

Washington,  D.C.:  24  November  1976. 

21.  _ .  Department  of  Defense  Directive  5000.3:  Test  and  Evaluation. 

Washington,  D.C.:  26  December  1979. 

22.  _ .  Department  of  Defense  Instructions  5000. XXA:  Interim  List  of 

DOD  -  Approved  Computer  Architecture.  Washington,  D.C.:  19 

April  1978. 

23.  _ .  Department  of  Defense  Directive  5000,1:  Major  System 

Acquisition.  Washington,  D.C.:  19  March  1980. 

24.  _ .  Department  of  Defense  Instruction  5000.2:  Major  System  Acquisi- 

tion  Procedures.  Washington,  D.C.:  19  March  1980. 

25.  US  Department  of  the  Army.  Army  Regulation  1 1 -28 :  Economic  Analysis 

and  Program  Evaluation  for  Resource  Management.  Washington,  D.C.: 

2  December  1975. 

26.  _ .  Army  Regulation  15-14:  Systems  Acquisition  Review  Council 

Procedures.  Washington,  D.C.:  1  April  1978. 


A-3 


27.  US  Department  of  the  Army.  Army  Regulation  70-1:  Army  Research, 

Development,  and  Acquisition?  Washington,  D.C.:  1  February  1977. 

28.  _ .  Army  Regulation  70-27:  Outline  Development  Plan/Development 

Plan/Army  Program  Memorandum/Defense  Program  Memorandum/Decision 
Coordinating  Paper.  Washington,  D.C.:  17  March  1975. 

29.  .  Army  Regulation  70-37:  Configuration  Management.  Washington, 

D.C.:  19  July  1976. 

30.  _ .  Army  Regulation  71-9:  Materiel  Objectives  and  Requirements. 

Washington,  D.C.:  7  February  1975. 

31.  _ .  Army  Regulation  700-127:  Integrated  Logistic  Support. 

Washington,  D.C.:  11  April  1975. 

32.  _ .  Headquarters,  US  Army  Materiel  Development  and  Readiness  Command 

DARCOM  Regulation  70-1:  Transition  of  Management  Responsibility 
from  a  Research  and  Development  Command  Manager  to  a  Materiel 
Readiness  Command  Manager.  Fort  Belvoir. 

33.  _ .  Army  Regulation  71-1:  Force  Development,  Army  Combat 

Developments!  Washington,  D.C.:  25  June  1969. 

34.  US  Department  of  the  Air  Force.  Air  Force  Regulation  800-14:  Volume  I: 

Management  of  Computer  Resources  in  Systems;  Volume  II:  Acqui¬ 
sition  and  Support  Procedures  for  Computer  Resources  in  Systems. 
Washington,  D.C.:  26  September  1975. 

35.  US  Department  of  the  Army.  Army  Regulation  18-1:  Management  Information 

Systems,  Policies,  Objectives,  Procedures,  and  Responsibilities. 
Washington,  D.C.:  22  March  1976.  (With  TRAD0C  Supplement  1, 

10  September  1976.);  Army  Regulation  18-1:  Army  Automation,  Army 
Automation  Management.  Washington,  D.C.:  15  August  1980. 

(Without  accompanying  Technical  Bulletins.) 

36.  _ .  Headquarters,  US  Army  Materiel  Development  and  Readiness  Command 

DARCOM  Regulation  70-16:  Management  of  Computer  Resources  in 
Battlefield  Automation  Systems.  Fort  Belvoir:  16  July  1979. 

37.  _ .  Army  Regulation  1000-1:  Basic  Policies  for  Systems  Acquis¬ 

ition.  Washington,  D.C.:  1  April  1978. 

38.  _ .  Army  Regulation  70-61:  Type  Classification  of  Army  Materiel. 

Washington,  D.C.:  1  August  1978. 


39. 


.  Army  Regulation  70-15:  Research  and  Development,  Product 
Improvement  of  Materiel.  Washington,  D.C.:  15  June  1980. 


40.  US  Department  of  the  Army.  Army  Regulation  380-380:  Automated  Systems 

Security.  Washington,  D.C.:  15  April  1979. 

41.  _ .  Army  Regulation  70-10:  Test  and  Evaluation  During  Development 

and  Acquisition  of  Materiel.  Washington,  D.C.:  29  August  1975. 

42.  _ .  Army  Regulation  70-17:  System/Program/Project/Product 

Management.  Washington,  D.C.:  11  November  1976. 

43.  _ .  Army  Regulation  10-41:  United  States  Army  Training  and 

Doctrine  Command.  Washington,  D.C.:  27  June  1973. 

44.  _ .  Army  Regulation  10-11:  United  States  Army  Materiel  Development 

and  Readiness  Command.  Washington,  D.C.:  9  March  1977. 

45.  US  Department  of  Defense.  Military  Standard  483:  Configuration 

Management  Practices  for  Systems,  Equipment,  Munitions,  and 
Computer  Programs.  Washington,  D.C.:  31  December  1970. 

46.  _ .  Military  Standard  490A:  Specification  Practices.  Washington, 

D.C. :  30  October  1968. 

47.  US  Department  of  the  Air  Force.  Air  Force  Systems  Command  Pamphlet 

800-7:  Configuration  Management.  Washington,  D.C.: 

1  December  1977. 

48.  US  Department  of  the  Army.  Headquarters,  US  Army  Development  and 

Readiness  Command.  DARCOM  Circular  702-4:  Army  Defense  Systems 
Software  Control  During  the  Production  and  Deployment  Phase. 

Fort  Belvoir:  28  March  1978. 

49.  _ .  Pamphlet  11-25:  life  Cycle  System  Management  Model  for  Army 

Systems.  Washington,  D.C.:  21  May  1975. 

50.  _ .  Pamphlet  70-21:  The  Coordinated  Test  Program  (CTP). 

Washington,  D.C.:  10  May  1976. 

51.  _ .  Headquarters,  US  Army  Training  and  Doctrine  f  nd.  TRADOC 

Pamphlet  71-3:  Force  Development,  Combat  Dev^o*  ts  Study 
Writing  Guide.  Fort  Monroe:  1  June  1977. 

52.  _ .  Army  Regulation  AR  10-1:  Organization  and  Functions, 

Functions  of  the  Department  of  Defense  and  Its  Major  Components. 
Washington,  D.C.:  6  January  1977. 


53. 


.  Headquarters,  US  Army  Training  and  Doctrine  Command.  TRADOC 
Regulation  10-5:  Organization  and  Functions.  Fort  Monroe: 

10  December  1979. 


A-5 


54.  US  Department  of  the  Army.  Headquarters,  US  Army  Training  and  Doctrine 

Command.  TRADOC  Regulation  10-41:  Organization  and  Functions, 
Mission  Assignments.  Fort  Monroe:  1  May  1980. 

55.  _ .  Army  Regulation  10-4:  Organization  and  Functions,  US  Army 

Operational  Test  and  Evaluation  Agency.  Washington,  D.C.: 

30  December  1974. 

56.  _ .  Army  Regulation  570-2:  Manpower  and  Equipment  Control, 

Organization  and  Equipment  Authorization  tables  —  Personnel. 
Washington,  D.C.:  15  September  1978. 

57.  _ .  Headquarters,  US  Army  Training  and  Doctrine  Command.  TRADOC 

REGULATION  71-1:  Force  Development,  US  Army  Training  and  Doctrine 
Command  (TRADOC)  Management  Information  System  (TRAMIS)  (RCS  A 
TRM  -  38).  Fort  Monroe:  1  September  1976.  (With  CAC  and  Fort 
Leavenworth  Supplement  1-15  June  1978.) 

58.  _ .  Headquarters,  US  Army  Training  and  Doctrine  Command.  TRADOC 

Regulation  71-3:  Force  Development,  Acceptance  and  Assignment 
of  New  Combat  Development  Tasks.  Fort  Monroe:  2  May  1977. 

59.  _ .  Army  Regulation  71-3:  Force  Development,  User  Testing. 

Washington,  D.C.:  8  March  1977. 

60.  _ .  Headquarters,  US  Army  Training  and  Doctrine  Command.  TRADOC 

Regulation  71-12:  Force  Development,  Total  System  Management  - 
TRADOC  System  Manager  (TSM).  Fort  Monroe:  15  September  1978. 

61.  _ .  Army  Regulation  5-5:  Management,  The  Army  Study  System. 

Washington  D.C.:  15  April  1978. 

62.  _ .  Army  Regulation  70-16:  Research  and  Development,  Department 

of  the  Army  System  Coordinator  (DASC)  System.  Washington,  D.C.: 

20  March  1975. 


63. 


_.  Army  Regulation  700-129:  Integrated  Logistics  Support 
Management  of  Multi service  Communications  Electronics  Systems 
and  Equipment.  Washington,  D.C.:  11  January  1980. 


64.  _ .  Army  Regulation  70-9:  Research  and  Development,  Army 

Research  and  Development  Information  System  Planning  and 
On-Going  Work  Reporting.  Washington,  D.C.:  22  August  1973. 


65. 


_.  Army  Regulation  611-1:  Personnel  Selection  and  Classification, 
Military  Occupational  Classification  Structure  Development  and 
Implementation.  Washington,  D.C.:  27  April  1976. 


A- 6 


66.  US  Department  of  the  Army.  Army  Regulation  37-200:  Financial  Admin¬ 

istration,  Selected  Acquisition  Information  and  Management 
Systems  (SAIMS).  Washington,  D.C.:  1  December  1979. 

67.  _ .  Army  Regulation  71-2:  Force  Development,  Basis  of  Issue  Plan. 

Washington,  D.C.:  19  April  1976. 

68.  _ .  Headquarters,  US  Army  Training  and  Doctrine  Command.  TRADOC 

Regulation  11-5:  Army  Programs,  Cost  Analysis  Program,  (MOS 
Training  Costs)  RCS  A  TRM  -  159.  Fort  Monroe:  5  September  1975. 

69.  _ .  Headquarters,  US  Army  Training  and  Doctrine  Command.  TRADOC 

Regulation  11-12:  Army  Programs,  TRADOC  Resource  Factors  (Require- 
ment  Control  Symbol  ATR  M  -  54  (Rl)).  Fort  Monroe:  11  January  1980. 

70.  _ .  Headquarters,  US  Army  Training  and  Doctrine  Command.  TRADOC 

Regulation  11-2:  Army  Programs,  Priorities  and  Tasking  Control. 

Fort  Monroe:  15  February  1980. 

71.  _ .  Headquarters,  US  Army  Materiel  Development  and  Readiness 

Command/Headquarters,  Army  Training  and  Doctrine  Command. 
DARCOM/TRADOC  Materiel  Acquisition  Handbook.  Alexandria/Fort 
Monroe:  1  January  1980. 

72.  _ .  Headquarters,  US  Army  Training  and  Doctrine  Command.  TRADOC 

Regulation  71-9:  Force  Development,  User  Testing  and  Evaluation. 

Fort  Monroe:  1  October  1978. 

73.  _ .  DA  Pamphlet  5-5:  Guidance  for  Study  Sponsors  and  Study 

Advisory  Groups.  Washington,  D.C.:  18  October  1976. 

74.  _ .  Office  of  the  Assistant  Chief  of  Staff  for  Automation  and 

Communications.  Alignment  of  Automation  and  Communications 
Functions  of  Army  Agencies  and  Commands  (SAACFAAC).  Study  Final 
Report.  Washington,  D.C.:  31  July  1980. 

75.  _ .  Headquarters,  US  Army  Computer  Systems  Command.  USACSC 

Regulation  18-21:  Management  Information  Systems,  Command 
Customer  Assistance  Program.  Fort  Belvoir:  5  December  1979. 

76.  _ .  Office  of  the  Assistant  Secretary.  Memorandum  for  Deputy 

Chief  of  Staff  for  Research,  Development,  and  Acquisition. 

Washington,  D.C.:  1  July  1980. 

77.  _ .  Headquarters,  US  Army  Logistics  Center.  LOGC  Regulation  10-1: 

Organization  and  Functions.  Fort  Lee:  1  January  1980. 


78. 


_.  US  Army  Intelligence  Center  and  School.  USAICS  Regulation  10-1 
Organization  and  Functions  USAICS  Organization,  Mission,  and 
Functional  Manual.  Fort  Huachuca:  1  October  1979. 


A-7 


79.  US  Department  of  the  Army.  Headquarters,  US  Army  Training  and  Doctrine 

Command.  TRADOC  Circular  351-8:  Schools,  Individual  and 
Collective  Training  Plan  for  Developing  Systems  Policy  and 
Procedures.  Fort  Monroe:  1  May  1980. 

80.  _ .  Headquarters,  US  Army  Air  Defense  Center  and  Fort  Bliss.  USAADCENFB 

Regulation  10-1:  Organization  and  Functions,  Manual  of  Organization, 
Missions,  and  Functions.  Fort  Bliss:  15  September  1980. 

81.  _ .  Headquarters,  US  Army  Computer  Systems  Command.  USACSC 

Regulation  18-23:  Management  Information  Systems,  Automated  Data 
Systems  Configuration  Management  Program.  Fort  Bel  voir: 

1  December  1979. 

82.  _ .  Headquarters,  US  Army  Training  and  Doctrine  Command.  TRADOC 

Circular  351-8:  Schools,  Individual  and  Collection  Training  Plan 
for  Developing  Systems  Policy  and  Procedures.  Fort  Monroe: 

I  May  1980. 

83.  United  States  Army  Signal  School.  USASIGS  Regulation  10-2:  Organization 

and  Functions  Manual.  Fort  Gordon:  18  May  1977. 

84.  US  Department  of  the  Army.  Headquarters,  US  Army  Field  Artillery  Center 

and  Fort  Sill.  USAFACFS  Regulation  10-1:  Organization  and 
Functions,  Manual  of  Organization  and  Functions.  Fort  Sill: 

II  April  1980. 

85.  _ .  Headquarters,  Combined  Arms  Center  and  Fort  Leavenworth. 

CAC  and  Ft  LVN  Regulation  10-1:  Organization  and  Functions. 

Fort  Leavenworth:  1  August  1980 

86.  _ .  Army  Regulation  10-5:  Organization  and  Functions.  Washington, 

D.C.:  1  November  1978. 

87.  _ .  Headquarters,  US  Army  Training  and  Doctrine  Command.  TRADOC 

Regulation  10-2:  Organizations  and  Functions,  Control  of 
Mission  Assignment  and  Organization  Structure.  Fort  Monroe. 

July  1973. 

88.  _ .  Headquarters,  US  Army  Logistics  Center.  LOGC  Regulation  10-1 : 

Organization  and  Functions.  Fort  Lee.  1  January  1980. 

89.  _ .  Office  of  the  Deputy  Commanding  General,  US  Army  Training  and 

Doctrine  Command.  Standardization  of  Embedded  Computer  Resources. 
Letter.  Fort  Leavenworth:  30  July  1980. 

90.  _ .  Headquarters,  US  Army  Communications  Research  and  Development 

Command.  CQRADCOM,  Master  Configuration  Management  Plan.  Fort 
Monmouth:  11  January  1980. 


A-8 


91.  US  Department  of  the  Army.  Headquarters ,  US  Army  Training  and  Doctrine 

Command,  General  Donn  A.  Starry.  Combat  Service 
Support  (CSS)  Doctrine  and  Automation  and  lommuni cations 
Archi tecture.  Message.  Fort  Monroe:  23  September  1980. 

92.  _ .  Project  Manager,  PATRIOT  Missile  System,  DARCOM.  Post-Deploy¬ 

ment  Software  Support  Implementation  Plan.  Redstone  Arsenal : 
January  1979. 

93.  _ .  Project  Manager,  Missile  Minder/Air  Defense  Tactical  Data 

Systems  (MM/ADTDS),  CORADCOM.  AN/TSQ-73  Post-Deployment  Manage¬ 
ment  Plan.  2nd  Revision.  Redstone  Arsenal:  25  June  1979. 

94.  _ .  US  Army  Military  Personnel  Center.  MILPERCEN  Supplement  1 

to  AR  10-5:  Organization  and  Functions.  Alexandria:  1  August 
1979. 

95.  _ .  Special  Study  Group.  Review  of  Army  Analysis:  Volume  I; 

Main  Report  and  Volume  II;  Appendixes  C-M.  Washington,  DC: 

April  1979. 


B-l 


APPENDIX  B 


GLOSSARY  1 
TERMS 

Air  Defense  BFA--This  BFA  reacts  to  and  defeats  a  varied  and  growing  aircraft 
and  countermeasures  threat  under  all  environmental  and  tactical  con¬ 
ditions  and  in  all  intensities  of  combat. 

Baseline  PDSS  System— The  personnel,  equipment,  organizational  structure,  and 
operating  procedures  presently  existing  within  TRADOC  that  are  employed 
in  accomplishing  PDSS  functions  for  which  that  command  is  responsible. 

Battlefield  Automated  System  (BAS)— A  system  which  contains  a  computer(s), 

is  intended  for  use  by  the  Army  in  the  field,  and  which  will  not  function 
without  computer(s);  e.g.,  AN/TSQ-73,  TACFIRE. 

Battlefield  Functional  Area  (BFA) — A  conceptual  grouping  of  Army  personnel, 
equipment,  and  procedures  which  together  perform  a  major  battlefield 
function.  The  BFAs  used  in  this  study  are  identified  in  Figure  1-1. 

Combat  Developer— The  agency  or  command  responsible  for  the  formulation  of 
concepts,  doctrine,  organization,  and  materiel  objectives,  and  require¬ 
ments  for  the  employment  of  U.S.  Army  Forces  in  a  theater  of  operations 
and  in  the  control  of  civil  disturbances.  The  Combat  Developer  formulates 
Army  functional  systems  (logistics,  personnel,  administrative,  and  others, 
as  designated)  which  impact  directly  on  or  extend  into  a  theater  of  oper¬ 
ations.  The  U.S.  Army  Training  and  Doctrine  Command  (TRADOC)  is  the  Army’s 
principal  Combat  Developer, 

Combat  Developer  PDSS  Liasion  Office  (CD  PDSS  LNO)— An  office  consisting  of 
one  or  more  Combat  Developer  personnel  who  represent  the  Combat  Developer 
and  User  on  PDSS  matters  pertaining  to  specified  BAS  at  a  Materiel  Develop¬ 
er  organization.  The  CD  PDSS  LNO  coordinates  and  facilitates  Combat 
Developer-Materiel  Developer  interaction. 

Combat  Development  Support  Facility  (CDSF)--The  CDSF  is  a  TRADOC  analytical 
facility  which  encompasses  one  or  more  BFAs  and  which  may  or  may  not  be 
collocated,  in  whole  or  in  part,  with  an  MD  PDSS  facility  at  the  TRADOC 
doctrine  center  or  school.  The  CDSF  has  as  its  primary  purpose  the 
provision  of  w^th  the  system/software  analytical  capability  and  the 
technical  per  nel  necessary  to  perform  CD  functions  in  the  development, 
maintenance,  application,  and  training  for  BAS  in  order  to  develop,  field, 
use,  sustain,  and  evolve  these  systems.  It  should  be  noted  that  the 
CDSF  should  be  construed  more  as  a  physical  facility  than  an  organiza¬ 
tional  entity.  Like  a  command  post,  the  CDSF  is  essentially  a  place 
where  equipment  and  personnel  from  various  organizational  entities  are 
collocated  and  structured  to  most  effectively  perform  certain  PDSS 
functions,  when  or  as  required.  The  CDSF,  with  respect  to  both  the 
physical  facility  itself  and  the  staff  entities  located  within  it,  may 
be  either  permanent  or  temporary. 
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Combat  Development  System  Manager  (CDSM)--The  Combat  Developments  System 

Manager  (CDSM)  is  the  system/software  CD  and  the  principal  Field  User's 
representative  for  a  designated  system  or  systems.  The  CDSM  is  respon¬ 
sible  for  managing  and  coordinating  and/or  performing  all  software-re¬ 
lated  actions  inherent  in  the  CD  mission.  The  CDSM  is  also  responsible 
for  planning,  programming,  and  coordinating  those  software  tasks  required 
to  be  performed  by  the  CDSF  in  support  of  the  systems  for  which  he  is 
responsible. 

Combat  Service  Support  8FA--This  BFA  supports  the  commander  at  each  tactical 
echelon  in  seeing  the  battlefield  and  sustaining  the  force  by  providing 
decisive  and  timely  personnel,  administrative,  and  logistical  support 
and  technical  expertise  as  far  forward  as  possible,  to  give  the  command 
a  full  complement  of  personnel,  operating  equipment,  and  weapons. 

Support  is  also  provided  to  all  other  BFA. 

Communications  Functional  Area--This  functional  area  provides  the  mechanism 
by  which  the  commander  controls  all  other  battlefield  functions  in  the 
performance  of  his  mission. 

Fire  Support  BFA--This  BFA  is  the  major  contributor  of  fire  support  for 
maneuver  forces  to  include  Field  Artillery. 

Force  Level  Control  Functional  Area--This  functional  area  is  the  exercise  of 
the  inherent  authority  of  a  commander  to  plan,  direct  and  monitor  im¬ 
plementation  of  tasks  by  subordinate  elements  within  all  Battlefield 
Functional  Areas. 

Functional  Proponent--The  Army  Staff  agency  responsible  for  the  subject 

area  in  which  automation  is  used  or  is  to  be  used,  including  automation 
in  support  of  the  function  performed. 

Hybrid  PDSS  System--The  conceptual  system  consisting  of  personnel,  equipment, 
facilities,  organizational  structure,  and  operating  procedures,  derived 
during  this  study  from  a  comparative  analysis  of  the  PDSS  Baseline  and 
Theoretical  Systems,  which  incorporates  the  desirable  features  of  each 
of  those  systems,  and  which  would  provide  TRADOC  a  capability  to  fulfill 
its  role  and  responsibilities  in  providing  PDSS  for  BAS. 

Intelligence  Surveillance  and  Electronic  Warfare  BFA--This  BFA  assists  the 
commander  and  his  staff  in  knowing  and  understanding  the  enemy  and  in 
seeing  the  battlefield  through  surveillance  and  target  acquisition.  In 
its  electronic  capability  this  BFA  attacks  or  defends  systems  that  employ 
electromagnetic  energy,  including  cormand  and  control,  weapon  and 
acquisition  systems. 
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Maneuver  BFA--This  BFA,  through  its  inherent  subsystems  of  direct  fire  and 
integration  provides  the  timely  means  to  generate  and  apply  decisive 
combat  power  on  the  modern  battlefield.  Also  included  in  this  BFA  are 
the  functional  areas  of  Air/Ground,  Engineer  and  that  portion  of  Command 
and  Control  in  the  area  of  planning. 

Materiel  Developer— The  command  or  agency  responsible  for  research,  develop¬ 
ment,  and  production  validation  of  an  item  (including  the  system  for  its 
logistic  support)  which  responds  to  DA  objectives  and  requirements. 

Post-Deployment  Software  Support  (PDSS)--is  that  part  of  overall  system  support 
necessary  to  sustain,  modify,  and  improve  a  deployed  system's  computer 
software,  as  defined  by  the  User  or  his  representative.  It  includes 
evaluation,  development,  and  timely  implementation  of  system  and  software 
modifications  to  accommodate  trouble  reports;  User  proposed  changes;  and 
changes  to  satisfy  new  or  revised  doctrinal,  tactical,  procedural  or 
interoperability  requirements. 

Post-Deployment  Software  Support  (PDSS)  Center— A  facility,  managed  by  the 
Materiel /System  Developer,  with  necessary  equipment  and  personnel  to 
provide  PDSS  to  designated  BAS. 

Priorities  on  Tasking  Control  Process  (TRADOC  Regulation  11-12),  by  which 

Proponent  Agency  (PA)— The  element  assigned  responsibility  by  the  functional 
proponent  for  the  functional  design,  development,  implementation,  and 
maintenance  of  an  automated  system. 

Theoretical  PDSS  System— The  conceptual  system  consisting  of  personnel, 

equipment,  facilities,  organizational  structure,  and  operating  procedures 
determined  during  this  study  to  be  needed  within  TRADOC  to  enable  that 
command  to  fulfill  its  role  and  responsibilities  for  providing  PDSS  for 
BAS,  within  the  context  of  Army  regulatory  policy  and  the  PDSS  Concept 
Plan  for  BAS. 

User— The  conmand  or  agency  ultimately  intended  to  employ  an  item  of  equipment 
and  so  designated  by  DCSOPS  (AR  1000-1)  when  approving  the  requirement 
document.  The  User  or  Users  representative  provides  guidance  to  the 
developer  throughout  the  materiel  acquisition  process  on  matters  per¬ 
taining  to  the  expected  operational  employment  of  the  item.  Unless 
another  command  is  so  designated,  TRADOC  will  act  as  the  User  repre¬ 
sentative  and  will  carry  out  the  "User"  functions. 
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GLOSSARY  2 
ACRONYMS 


AAH— Advanced  Attack  Helicopter 

ADP— Automatic  Data  Processing 

AMIP — Army  Models  Improvement  Program 

ARRADCOM- -Armaments  Research  and  Development  Command 

ASAS-- All -Source  Analysis  System 

BAS--Battlefield  Automated  Systems 

BCS--Battery  Computer  System 

BFA--Battlefield  Functional  Area 
3 

BS  0--Battlefield  Systems  Software  Support  Organization 

BSI--Battlefield  Systems  Integration  Directorate 

C  A  E--Communications-Electronics 

C  &  S--Concepts  and  Studies 
2 

C  --Command  and  Control 

C^I--Command,  Control,  Conrninications ,  and  Intelligence 
CAA--Concepts  Analysis  Agency 
CAC--Combined  Arms  Center 

CACDA-- Combined  Arms  Combat  Development  Activity 

CASAA- -Combined  Arms  Studies  and  Analysis  Activity 
2 

CCS  --Command,  Control,  and  Subordinate  System 
CD--Combat  Developer 

CD  PDSS  LN0--Combat  Developer  PDSS  Liaison  Office 
CDSF--Combat  Development  Support  Facility 
CDSM--Combat  Development  System  Manager 
C-E--Communications-Electronic 
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CMSR--Communi cations  Support  Requirements 

CORADCOM--Communi cations  Research  and  Development  Command 

COTR--Contracting  Officer's  Technical  Representative 

CRMP--Computer  Resources  Management  Plan 

CSS — Combat  Service  Support 

CSSD--Combat  Systems  Software  Division 

DARC0M--US  Army  Materiel  Development  and  Readiness  Command 

DCD--Directorate  of  Combat  Developments 

DCSCD--Deputy  Chief  of  Staff  for  Combat  Developments 

DCSPER--Deputy  Chief  of  Staff  for  Personnel 

DDCD- -Directorate  of  Doctrine  and  Combat  Development 

DMD--Oigital  Message  Device 

DPF0--Data  Processing  Field  Office 

DT--Development  Testing 

DTD--Di rectorate  of  Training  Developments 

EAC--Echelon  Above  Corps 

ECP--Engineering  Change  Proposal 

ERADCOM--Electronic  Research  and  Development  Command 
EW--Electronic  Warfare 

CATDS— Field  Artillery  Tactical  Data  Systems 

FC--Force  Control 

FDS--Fire  Direction  System 

GPS--Global  Positioning  System 

HQDA— Headquarters,  Department  of  the  Army 

INSCOM— US  Army  Intelligence  and  Security  Command 
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IOC — Initial  Operating  Capability 

JINTACCS--Joint  Interoperability  of  Tactical  Command  and  Control  Systems 
JTE--Joint  Test  Element 
LOGCEN--Logi sties  Center 

MAINSITE--Modular  Automated  Integrated  System  Interoperability  Test  and 
Evaluation 

MC--Maneuver  Control 

MD--Materiel  Developer 

MICOM--Missile  Command 

MILPERCEN--Military  Personnel  Center 

MISD--Management  Information  System  Directorate  (Division) 

MLRS--Multiple  Launch  Rocket  System 
MOU- -Memorandum  of  Understanding 
NET--New  Equipment  Training 
0TEA--0peration,  Test  and  Evaluation  Agency 
PDSS--Post-Deployment  Software  Support 
PERMIS--New  Personnel  System 
PII--Pershing  II 

PLRS--Position  Location  Reporting  System 
POM- -Program  Objective  Memorandum 
PPBS--Planning,  Programming,  and  Budgeting  System 
PTC--Priori ties  and  Tasking  Control  Process 
PWIS--Prisoners  of  War  Information  System 
SAG--Study  Advisory  Group 

SIDPERS--$tandard  Installation  Division  Personnel  System 
SSC--Soldier  Support  Center 


TACFIRE — Tacti cal  Fire  Control  System 

TAMMIS--Theater  Army  Medical  Management  Information  System 

TAPER--Theater  Army  Personnel  Rollup 

TC4S--Telecommunications,  Command  and  Control,  and  Computer  Systems 

TCATA--TRADOC  Combined  Arms  Test  Activity 

TDS--Tactical  Data  Systems 

USE— Tactical  Interoperability  Support  Element 

TRADOC— US  Army  Training  and  Doctrine  Command 

TRASANA--TRADOC  Systems  Analysis  Agency 

TSS6--TACFIRE  Software  Support  Group 

TSM— TRADOC  System  Manager 

USAADS— US  Army  Air  Defense  School 

USACC--US  Army  Communications  Command 

USACSC— US  Army  Computer  Systems  Command 

USAFAB--US  Army  Field  Artillery  Board 

USAFAS--US  Army  Field  Artillery  School 

USAICS--US  Army  Intelligence  Center  and  School 

USAREUR— United  States  Army  Europe 

USASC--US  Army  Signal  Center 

USASC  &  FG— US  Army  Signal  Center  and  Fort  Goron 

VFDMIS— Vertical  Force  Development  Information  ystem 

VTAADS— Vertical  The  Army  Authorization  Document  Systems 
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APPENDIX  C 

BATTLEFIELD  AUTOMATED  SYSTEMS  (BAS) 


i  C-1.  CONTENT  OF  APPENDIX.  This  appendix  contains  the  Battlefield  Automated 

Systems  (BAS)  addressed  during  this  Post-Deployment  Software  Support  (PDSS) 

I  Study  organized  by  their  Battlefield  Functional  Area  (BFA).  Consistent  with 

current  doctrinal  literature,  there  are  now  considered  to  be  five  BFA's  and 
two  functional  areas  instead  of  the  11  former  BFA's  that  were  recognized. 

Figure  C-l  clarifies  this  new  classification  in  relationship  to  the  11  former 
BFA’s.  Figures  C-2  through  C-8  list  the  systems  according  to  this  new  class¬ 
ification  and  identify  the  system  proponent,  development  cormiand,  readiness 
command,  and  projected  PDSS  center. 

C-2.  SYSTEM  CATEGORIES.  The  focus  of  this  study  has  been  on  System  Categories 
1 ,  2A  and  2B  as  defined  in  the  PDSS  Concept  Plan  for  BAS,  May  1980,  since 
those  are  the  systems  with  which  TRADOC  is  principally  concerned  with  respect 
to  PDSS: 

a.  Category  1  systems  are  defined  as  large  ^over  100K  lines  of  code) 
evolutionary  systems  and  include  SIGMA,  ASAS,  TACFIRE,  AN/TSQ-73,  PATRIOT, 

CSS  Control  System,  AN/MSM-105(V) ,  and  PLRS/JTIDS  Hybrid. 

b.  Category  2A  systems  are  defined  as  small  (less  than  100K  lines  of 
code)  evolutionary  systems,  e.g.,  DIVAD  GUN,  Battery  Computer  System  (BCS), 
and  SHORAD  C2. 

c.  Category  2B  systems  include  large  stable  systems,  e.g.,  PLRS,  SOTAS, 
and  ADOS. 

d.  Category  3  systems  are  small  stable  systems  in  which  the  software 
is  normally  transparent  to  the  user  and  is  not  expected  to  change  greatly 
once  the  system  is  fielded. 

C-3.  CATEGORIZATION  SOURCE.  The  above  system  categorization,  used  during 
this  study  was  accomplished  durinq  a  previous  DARCOM-initiated  study,  Post- 
Deployment  Software  Support  (PDSS)  Concept  Plan  for  Battlefield  Automated 
Systems,  May  19&0. 
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BATTLEFIELD  FUNCTIONAL  AREAS  (BFA) 

FORMER  CLASSIFICATION 

1 .  FORCE  LEVEL  CONTROL  BFA 

FORCE  LEVEL  CONTROL  FUNCTIONAL  AREA 
(THAT  PORTION  WHICH  AFFECTS  THE 
COMMANDER  AND  HIS  STAFF  IS  NOW  CON¬ 
SIDERED  TO  BE  IN  THE  FORCE  LEVEL 
CONTROL  AREA  AND  TO  INTERACT  WITH 

THE  FIVE  BFA'S  LISTED  BELOW.) 

2.  MANEUVER  BFA 

3.  AIR  GROUND  BFA 

4.  ENGINEER  BFA 

1.  MANEUVER  BFA  (ALSO  INCLUDES  THAT 
PORTION  OF  COMMAND  AND  CONTROL 

IN  THE  AREA  OF  PLANNING.) 

5.  AIR  DEFENSE  BFA 

2.  AIR  DEFENSE  BFA 

6.  FIRE  SUPPORT  BFA 

3.  FIRE  SUPPORT  BFA 

7.  LOGISTICS  BFA 

8.  ADMINISTRATION  BFA 

4.  COMBAT  SERVICE  SUPPORT  BFA 

9.  INTELLIGENCE  BFA 

10.  ELECTRONIC  WARFARE  BFA 

5.  INTELLIGENCE  AND  ELECTRONIC 
WARFARE  BFA 

11.  COMMUNICATIONS  BFA 

COMMUNICATIONS  FUNCTIONAL  AREA  (IS 

NOW  CONSIDERED  TO  BE  A  SUPPORT 
FUNCTIONAL  AREA  WHICH  SUPPORTS  AND 
INTERACTS  WITH  THE  FIVE  BFA'S 

LISTED  ABOVE.) 

Figure  C-l.  Classification  of  the  current  functional  areas  in 
relationship  to  the  11  former  BFA's 


Figure  C-2.  Force  Level  and  Maneuver  Control 
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Figure  C-3  (concluded) 


Figure  C-4.  Air  Defense  BFA  Systems 
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Figure  C-5.  Fire  Support  BFA  Systems  (continued  on  next  page) 
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Not  categorized  but  treated  as  Category  2  for  PDSS  planning. 

Figure  C-6.  (continued) 


Not  categorized  but  treated  as  Category  2  for  PDSS  planning. 

Figure  C-6.  (continued) 


Figure  C-7.  Intelligence  and  Electronic  Warfare  BFA  Systems  (continued 
on  the  next  page) 
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Systems  for  which  a  DARCOM  PDSS  Center  is  not  required  or  for 
which  the  need  has  not  been  determined. 

Figure  C-8.  (concluded) 
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A  Note  About  this  Proposed  Implementation  Plan: 

Included  among  the  principal  actions  that  must  be  accomplished  in 
connection  with  implementing  the  Objective  PDSS  System  within  TRADOC  is 
the  completion,  staffing,  approval,  and  publication  of  this  Implementation 
Plan.  It  is  envisioned  that  these  actions  can  be  completed  by  late  August 
and  that  the  Implementation  Plan  can  be  distributed  soon  afterward. 

However,  prior  to  that  time,  certain  other  actions,  essential  to  the  total 
implementation  effort,  must  be  initiated  and  in  some  cases  completed.  Many 
other  implementation  actions  will  have  to  be  accomplished  after  issuance 
of  this  plan. 

To  provide  a  complete  picture  of  all  principal  actions  in  the  total 
implementation  effort,  this  plan  identifies  and  discusses  the  total  set 
of  actions—those  that  must  precede  the  publication  of  this  plan  as  well 
as  those  that  will  follow.  For  reference  purposes,  the  actions  that  pre¬ 
cede  publication  of  this  plan  are  referred  to  herein  as  Phase  I  actions. 

Those  that  follow  its  publication  are  referred  as  Phase  II  actions.  By 
including  the  total  set  of  actions,  a  draft  of  this  plan  can  be  used  as 
a  guide  by  TRADOC  organizations  that  will  be  responsible  for  the  early 
(Phase  I)  actions  as  well  as  guidance  and  authority  for  the  Phase  II  actions. 
The  language  used  in  the  body  of  this  proposed  plan  is  consistent  with 
the  concept  outlined  above  for  issuing  the  final  version  of  this  plan  in 
late  August/early  September.  For  example.  Phase  I  actions  are  referred 
to  as  if  they  have  been  completed.  Phase  II  actions  are  included  for  the 
reasons  stated  above. 
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APPENDIX  D 


US  ARMY  TRAINING  AND  DOCTRINE  COMMAND 
OBJECTIVE  POST-DEPLOYMENT  SOFTWARE  SUPPORT  SYSTEM 
IMPLEMENTATION  PLAN  (TRADOC  PDSS  PLAN) 


D-l .  INTRODUCTION. 

a.  General . 

(1)  Mission  and  functions.  Army  Regulation  10-41  assigns  the 
mission  and  defines  the  major  functions  of  the  United  States  Army  Training 
and  Doctrine  Command  (TRADOC).  Included  in  this  mission  is  the  responsi¬ 
bility  to  conduct  all  Combat  developments  not  assigned  by  Headquarters, 
Department  of  the  Army  (HQDA)  to  other  commands  and  agencies  and,  as  the 
Army's  principal  combat  developer,  guide,  coordinate,  and  integrate  the 
total  combat  development  effort  of  the  Army.  TRADOC  Regulations  10-5 

and  10-41  implement  this  Army  Regulation.  The  first  of  these  two  TRADOC 
Regulations  defines  the  organization  of  HQ  TRADOC  and  delineates  staff 
organization,  responsibilities,  and  functions.  TRADOC  Regulation  10-41 
prescribes  missions  and  principal  functions  of  major  elements  of  TRADOC. 

(2)  Derivation  of  post-deployment  software  support  responsibilities. 
Inherent  in  the  combat  developments  mission  assigned  by  HQDA  to  TRADOC, 

and  in  the  missions  and  functions  assigned  by  HQ  TRADOC  to  major  subordinate 
elements,  is  the  responsibility  for  fulfilling  the  combat  developer's 
role  in  the  development  and  life  cycle  management  and  support  of  battlefield 
automated  systems  (BAS).  An  integral  part  of  this  process  is  the  requirement 
to  participate  with  the  material  developer  in  planning  and  providing 
support  to  BAS  following  their  deployment  to  insure  that  the  software 
portion  of  these  systems  is  sustained,  modified,  and  improved  as  necessary 
to  satisfy  system  user  requirements.  These  actions  constitute  post¬ 
deployment  software  support  (PDSS). 

(3)  The  Combat  developer's  role  in  PDSS.  The  combat  developer's 
role  in  the  Army's  PDSS  process  has  not  been  well  defined  nor  broadly 
recognized  in  the  combat  developments,  materiel  developments,  or  user  commu¬ 
nities.  However,  the  ever-increasing  magnitude  and  complexity  of  the  require¬ 
ment  to  provide  PDSS  to  the  growing  number  of  BAS,  and  the  rapidly  escalating 
costs  of  providing  this  support,  make  it  imperative  that  the  combat  developer 
play  a  more  prominent  and  active  role  in  this  total  effort.  This  plan 
addresses  the  combat  developer's  PDSS  role,  the  functional  requirements 
associated  with  it,  and  provides  for  transitioning  from  the  present  situ¬ 
ation  to  implementation  of  the  capability  needed  to  adequately  fulfill  PDSS 
responsibilities. 

b.  Purpose.  This  plan: 

(1)  Oefines  the  combat  developer's  role  in  the  PDSS  process. 


(2)  Describes  the  objective  functional  and  management  structure  that, 
when  implemented,  will  provide  the  capability  needed  to  enable  the  combat 
developer  to  fulfill  this  role. 

(3)  Describes  a  phased,  step-by-step,  procedure  for  transitioning 
from  the  present  to  implementation  of  the  objective  system. 

c.  Scope.  This  plan  addresses  TRADOC-wide  requirements  associated 
with  PDSS  for  BAS  projected  for  deployment  through  the  mid-  to  late-1980s. 

d.  Authority.  The  authority  for  this  plan  derives  from  responsibilities 
implicit  in  the  combat  developments  mission  assigned  to  TRADOC  by  Army  Regula¬ 
tion  10-41  and  further  assigned  to  major  TRADOC  elements  by  TRADOC  Regulations 
10-5  and  10-41.  A  separate  TRADOC  regulation  is  being  prepared  which  will 
address  the  PDSS  functional  area  more  explicitly.  The  new  regulation  will 
serve  as  authority  for  actions  associated  with  PDSS  following  its  publication. 

e.  Appl icabil i ty.  This  plan  is  applicable  to  all  TRADOC  elements  that 
are  involved  with  any  facet  of  the  system  development  and  life  cycle  manage¬ 
ment  and  support  process. 

f.  Implementation.  Actions  required  by  this  plan  are  divided  into 

two  phases.  Phase  I  includes  those  actions  that,  because  of  time  constraints, 
had  to  be  initiated  prior  to  formal  issuance  of  this  plan.  Phase  I  covered 
the  period  from  early  March  through  August  1981.  Verbal  authority  of  the 
Commander,  TRADOC  provided  the  basis  for  proceeding  with  these  Phase  I 
actions.  Phase  II  includes  those  actions  to  be  initiated  following  the 
formal  issuance  of  this  plan.  Phase  II  actions  begin  in  late  August  1981 
and  continue  into  March  1982.  This  plan  provides  authority  for  proceeding 
with  these  Phase  II  actions.  The  plan  is  effective  for  implementation 
upon  receipt. 

g.  References.  Key  references  are  listed  in  Annex  I. 

h.  Assumptions.  This  plan  is  promulgated  based  on  the  assumptions 
listed  below.  Changes  in  any  of  the  areas  addressed  will  necessitate  develop¬ 
ment  and  issuance  of  corresponding  changes  to  this  plan. 

(1 )  Missions  and  PDSS  roles. 

(a)  The  mission  and  basic  role  of  the  materiel  developer  with 
respect  to  PDSS  will  remain  essentially  as  described  in  the  PDSS  Concept  Plan 
for  BAS,  May  1980  (Reference  18). 

(b)  The  mission  and  basic  role  of  the  combat  developer  with 
respect  to  PDSS  will  remain  essentially  as  described  in  the  PDSS  Concept  Plan 
for  BAS,  May  1980,  and  Volume  II,  First  Interim  Technical  Report  of  the  Assess¬ 
ment  of  the  Combat  Developer's  Role  in  Post-Deployment  Software  Support, 
September  30,  1980. 
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(c)  The  major  functional  responsibilities  of  TRADOC  centers 
and  schools  will  remain  generally  as  specified  in  TRADOC  Regulation  10-41 
and  the  respective  center  and  school  organization  and  functions  regulations. 

(2)  PDSS  Centers.  Materiel/system  developer-managed  PDSS  centers 
will  be  established  as  recommended  in  the  PDSS  Concept  Plan  for  BAS,  May  1980. 
The  11  recommended  centers  are  identified  in  Figure  1-2  of  Annex  II. 

(3)  BAS.  BAS  addressed  in  this  report  will  continue  to  be  develop¬ 
ed  and  enter  the  Army  inventory  through  1987,  generally  as  currently  projected. 
These  BAS  are  identified  in  Inclosure  C  to  Annex  II. 

(4)  Soldier  Support  Center-Military  Personnel  Center  relationships. 
The  division  of  responsibility  for  PDSS  and  related  functions  between  the 
Soldier  Support  Center  (SSC)  and  the  Military  Personnel  Center  (MILPERCEN) 
will  remain  as  stated  in  the  Memorandum  of  Agreement  signed  by  the  Deputy  Chief 
of  Staff  for  Personnel,  and  the  Commanders  of  TRADOC,  SSC,  and  MILPERCEN,  5-7 
August  1980  (Reference  23). 

i.  Organization  of  this  Plan.  The  remainder  of  the  body  of  this  im¬ 
plementation  plan  prescribes  responsibilities  for  its  execution,  specifies 
coordination  authority  and  requirements,  identifies  actions  to  be  accomplished, 
provides  an  implementation  schedule,  and  prescribes  reporting  requirements. 
Basic  references  are  listed  in  Annex  I.  A  detailed  description  of  the  TRADOC 
Objective  PDSS  System  is  contained  in  Annex  II.  That  description  includes 
introductory  material,  an  overview  of  the  system,  a  discussion  of  the 
concept  of  operations,  a  description  of  each  major  component  of  the  system, 
and  time  phased  estimates  of  resources  necessary  to  implement  each  component 
of  the  system.  These  resource  estimates  will  require  further  refinement  as 
detailed  implementation  planning  and  actions  are  conducted  at  each  center 
and  school.  Annex  III  contains  additional  detail  regarding  each  major  action 
to  be  accomplished  during  the  implementation  of  this  plan.  This  additional 
information  is  presented  in  tabular  form  to  facilitate  its  use  by  all  organi¬ 
zational  elements  involved  with  this  implementation  effort.  Annex  IV  provides 
additional  guidance  regarding  TRADOC  center  and  school  implementation  plans. 

D-2.  RESPONSIBILITIES  FOR  EXECUTING  THIS  PLAN. 

a.  HQ  TRADOC.  The  Deputy  Chief  of  Staff  for  Combat  Developments  (DCSCD) 
has  primary  HQ  TRADOC  staff  responsibility  for  the  execution  of  this  Implemen¬ 
tation  Plan.  In  discharging  this  responsibility  he  will: 

(1)  Designate  a  primary  action  office  within  HQ  TRADOC  to  implement 
the  plan  as  it  pertains  to  the  headquarters,  and  to  supervise  and  coordinate 
its  execution  throughout  TRADOC. 


(2)  Monitor  implementation  progress. 

(3)  Resolve  problems  and  conflicts  resulting  from  implementation. 
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(4)  Insure  that  implementation  is  appropriately  coordinated  with 
organizations  external  to  TRADOC,  in  particular  the  US  Army  Materiel  Develop¬ 
ment  and  Readiness  Command  (DARCOM)  and  the  US  Army  Computer  Systems  Command 
(USACSC).  Both  of  these  commands  will  be  establishing  and  operating  PDSS 
Centers  in  accordance  with  the  PDSS  Concept  Plan  for  BAS,  May  1980. 

(5)  Conduct  formal  periodic  reviews  of  the  status  of  the  TRADOC - 
wide  implementation  effort. 

(6)  Recommend  to  the  Commander,  TRADOC  changes  to  this  plan  as 

required. 


b.  Commander,  Combined  Arms  Center.  The  Commander,  Combined  Arms 
Center  (CAC),  as  the  TRADOC  PDSS  proponent,  has  primary  responsibility  to 
support  HQ  TRADOC  in  the  execution  of  this  plan  by  coordinating  and  integrat¬ 
ing  the  actions  of  all  centers  and  schools  involved  in  its  implementation. 

The  Commander  CAC  will: 

(1)  Designate  a  primary  action  office  within  CAC  for  implementation 
of  the  plan  as  it  pertains  to  that  center  and  to  serve  as  the  focal  point  for 
coordinating  and  integrating  all  efforts  associated  with  its  execution  through¬ 
out  TRADOC. 

(2)  Direct  the  preparation  and  execution  of  additional  detailed 
implementation  plans  relevant  to  CAC  as  may  be  required  in  accordance  with 
Annex  IV. 

(3)  Monitor  implementation  progress  and  submit  reports  as  specified 
in  Paragraph  D-6. 

(4)  Resolve  problems  and  conflicts  resulting  from  implementation 
actions,  at  CAC  or  at  other  centers,  that  are  within  his  authority;  coordinate 
the  resolution  of  other  matters  with  HQ  TRADOC. 

(5)  Coordinate  and/or  direct  the  coordination  of  implementation 
actions  as  appropriate  within  TRADOC  and  with  organizations  external  to  TRADOC, 
in  particular  with  DARCOM  and  USACSC  organizations  involved  with  the  establish¬ 
ment  and  operation  of  PDSS  Centers. 

(6)  Assist  the  DCSCD,  HQ  TRADOC,  in  planning  and  conducting  formal 
periodic  reviews  of  the  status  of  the  TRADOC-wide  implementation  effort. 

(7)  Recommend  to  HQ  TRADOC  changes  in  the  Implementation  Plan 
as  required. 

c.  Other  TRADOC  Integrating  Centers.  The  Commanders  of  TRADOC 's  other 
two  integrating  centers,  the  US  Army  Logistics  Center  (LOGCEN)  and  US  Army 
Soldier  Support  Center  (SSC),  are  responsible  for  the  execution  of  this  plan 
within  their  respective  centers  and  in  their  associated  schools  that  are 
affected  by  the  plan.  In  discharging  these  responsibilities,  each  of  these 
commanders  will: 
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(1)  Designate  a  primary  action  office  within  their  respective  centers 
for  implementation  of  the  plan  as  it  pertains  to  each  center  and  to  serve  as 
the  focal  point  for  coordinating  and  integrating  all  efforts  related  to  its 
execution  at  associated  schools. 

(2)  Direct  the  preparation  and  execution  of  additional  detailed 
implementation  plans  relevant  to  each  of  their  respective  centers  and  associated 
schools  as  may  be  required  in  accordance  with  Annex  IV. 

(3)  Monitor  implementation  progress  and  submit  reports  as  specified 
in  Paragraph  D-6. 

(4)  Coordinate  implementation  actions  as  appropriate  within  TRADOC 
and  with  organizations  external  to  TRADOC,  in  particular  with  USACSC  and 
MILPERCEN. 

(5)  Refer  problems  and  conflicts  resulting  from  implementation  that 
cannot  be  resolved  locally  to  the  Commander,  CAC  and/or  Commander,  TRADOC. 

(6)  Recommend  to  CAC  and/or  HQ  TRADOC  changes  in  the  Implementation 
Plan  as  required. 

d.  Other  TRADOC  Functional  and  Doctrinal  Centers.  The  Commanders  of 
other  TRADOC  functional  and  doctrinal  centers  that  are  impacted  by  this 
Implementation  Plan  are  responsible  for  its  execution  within  their  respective 
centers.  These  commanders  will: 

(1)  Designate  a  primary  action  office  within  their  respective  centers 
for  implementation  of  the  plan  as  it  pertains  to  each  center  and  to  serve  as 
the  focal  point  for  coordinating  actions  as  appropriate  with  other  centers  and 
organizations  both  internal  and  external  to  TRADOC. 

(2)  Direct  the  preparation  and  execution  of  additional  detailed 
implementation  plans  as  may  be  required  for  their  respective  centers. 

(3)  Monitor  implementation  progress  and  submit  reports  as  specified 
in  Paragraph  D-6. 

(4)  Refer  problems  and  conflicts  resulting  from  implementation 
actions  that  cannot  be  resolved  locally  to  the  Commander,  CAC  and/or  Commander, 
TRADOC. 

(5)  Recommend  to  CAC  and/or  HQ  TRADOC  changes  in  the  Implementation 
Plan  as  required. 

e.  Other  TRADOC  Elements.  The  commanders  of  other  TRADOC  organizations 
will  support  and  participate  in  the  execution  of  this  Implementation  Plan  as 
specifically  directed  or  tasked  by  the  Commander,  TRADOC. 
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0-3.  COORDINATION.  All  TRADOC  elements  involved  with  the  implementation  of 
this  plan  are  authorized  and  required  to  coordinate  all  actions  as  appropriate 
with  other  organizations,  both  internal  and  external  to  TRADOC,  consistent 
with  the  roles,  missions,  functional  responsibilities,  and  organizational 
relationships  specified  in  TRADOC  Regulations  10-5  and  10-41.  Problems 
encountered  in  effecting  coordination  that  cannot  be  resolved  between  the 
organizations  directly  involved  will  be  referred  to  the  Commander,  CAC,  and/or 
the  Commander,  TRADOC. 

D-4.  ACTIONS  TO  BE  ACCOMPLISHED.  This  part  of  the  plan  addresses  the  actions/ 
events  that  must  be  accomplished  beginning  in  March  1981  and  continuing  through 
March  1982  to  provide  the  framework  for  transitioning  from  the  present  to 
implementation  of  the  TRADOC  Objective  PDSS  System  described  in  Annex  II. 

Full  implementation  is  to  be  achieved  by  1987. 

a.  Organization  of  Required  Actions.  It  should  be  noted  that  certain 
of  the  actions  identified  are  concerned  with  the  final  development  and  approval 
of  this  plan  itself,  and,  therefore,  were  accomplished  prior  to  the  formal 
approval  and  distribution  of  this  plan.  These  preliminary  implementation  actions 
and  other  actions  that  also  had  to  be  initiated  prior  to  distribution  of  this 
plan  are  considered  to  constitute  Phase  I  of  the  implementation  effort.  These 
Phase  I  actions  are  included  here  to  provide  a  complete  listing  of  all  principal 
actions/events.  Other  required  actions,  which  are  to  be  accomplished 
following  formal  approval  and  distribution  of  the  final  version  of  this 
Implementation  Plan,  constitute  Phase  II  of  the  implementation  effort. 

The  Phase  II  actions  are  also  addressed  in  this  plan. 

b.  Discussion  of  Required  Actions.  Each  principal  action/event  that 
must  be  accomplished  as  part  of  the  total  implementation  effort  (both 
Phases  I  and  II)  is  discussed  below,  generally  in  the  sequence  in  which 
the  actions  should  be  initiated.  Each  action  or  event  is  numbered  for 
ease  of  identification  and  subsequent  reference.  Additional  details 
relative  to  each  of  these  actions/events  is  presented  in  Annex  III  in 
tabular  form  to  facilitate  the  use  of  this  information  by  all  TRADOC 
elements  involved  with  the  execution  of  this  plan.  Annex  III: 

(1)  Identifies  and  describes  the  principal  actions  and  events 
that  must  be  accomplished  to  complete  this  implementation  effort. 

(2)  Organizes  these  actions  and  events  into  a  logical  sequence  that 
should  or  in  some  cases  must  be  followed,  associates  each  with  an  action/ 
event  number  for  subsequent  identification  and  reference  purposes,  and 
indicates  the  time  period  in  which  the  action  is  to  be  initiated. 

(3)  Indicates  the  TRADOC  organization(s)  responsible  for  each 
action/event. 

(4)  Identifies  and  briefly  describes  the  product(s)  or  other  results(s) 
of  each  action/event. 
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c.  Phase  I  Actions/Events.  The  principal  Phase  I  actions  and  events 
are  presented  and  discussed  below.  They  began  in  March  1981  and  continued 
through  August  1981.  A  schedule  is  presented  in  Annex  III, 

Action/Event  1:  Receive  and  review  the  final  documentation  (Volumes  I, 

II,  III,  and  IV)  of  the  TRADOC  PDSS  Study.  This  action,  applicable  to  all 
elements  of  TRADOC,  is  to  insure  that  all  TRADOC  personnel  involved  with  vhe 
execution  of  this  plan  have  a  common  understanding  of  the  background,  purpose, 
and  results  of  the  TRADOC  PDSS  Study. 

Action/event  2:  Prepare  material  for  the  First  Formal  TRADOC  PDSS  Review. 
This  action,  primarily  involving  HQ  TRADOC  and  CAC/CACDA,  is  to  prepare 
appropriate  information  for  presentation  and  discussion  at  the  First  Formal 
TRADOC  PDSS  Review  planned  for  late  March  1981. 

Action/event  3:  Provide  inputs  for  the  First  Formal  TRADOC  PDSS  Review 
as  requested.  This  action,  applicable  to  all  TRADOC  centers  and  schools,  is 

to  insure  that  the  views  and  interests  of  each  center  and  school  are  con¬ 

sidered  and  appropriately  addressed  in  the  First  Formal  TRADOC  PDSS  Review. 

Action/event  4:  Conduct  the  First  Formal  TRADOC  PDSS  Review  and  receive 
results  of  the  review.  This  action  involves  HQ  TRADOC  and  CAC/CACDA  with 
participation  as  appropriate  by  other  centers  and  schools. 

Action/event  5:  Revise  the  Draft  TRADOC  PDSS  Implementation  Plan  (this 
plan)  based  on  results  of  the  First  Formal  TRADOC  PDSS  Review.  This  action 
is  the  responsibility  of  CAC/CACDA  and  is  to  incorporate  all  quidance  and 

decisions  resulting  from  the  First  Formal  TRADOC  PDSS  Review  into  a  final 

version  of  the  TRADOC  PDSS  Plan  for  execution  throughout  TRADOC. 

Action/event  6:  Begin  detailed  PDSS  planning.  Centers  and  schools  in¬ 
itiate  the  development  of  detailed  PDSS  plans  based  on  results  of  the  First 
Formal  TRADOC  PDSS  Review  and  other  guidance  to  date.  See  Annex  IV  for 
further  details. 

Action/event  7:  Develop  a  First  Draft  of  the  proposed  TRADOC  PDSS 
Regulation.  This  action  is  the  responsibility  of  CAC/CACDA.  This  proposed 
regulation  is  to  establish  policy  and  assign  responsibilties  for  TRADOC  parti¬ 
cipation,  as  the  Army's  principal  combat  developer,  in  planning  for  and 
development,  acquisition,  testing,  training,  and  support  of  major  and  nonmajor 
Army  battlefield  automated  systems. 

Action/event  8:  Distribute  the  First  Draft  TRADOC  PDSS  Regulation  for 
review  and  comment.  This  action  by  CAC/CACDA  is  to  provide  for  a  TRADOC-wide 
review  of  the  proposed  regulation. 

Action/event  9:  Distribute  the  Draft  Implementation  Plan  (this  plan) 
for  coordination  or  comment.  This  action  by  CAC/CACDA  is  intended  to  obtain 
concurrence  with  the  final  draft  of  the  implementation  plan  prior  to  formal 
approval  and  issuance  of  the  plan  for  execution. 
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Action/event  10:  Issue  budget  instructions  for  PDSS  resources  for  FY  83. 
This  is  a  HQ  TRADOC  action.  Basic  budget  instructions  are  issued  by  HQ  TRADOC 
in  the  March-April  time  period,  too  early  to  incorporate  specific  budget 
instructions  relative  to  PDSS  resources.  The  purpose  of  issuing  these  supple¬ 
mental  budget  instructions  in  the  May-June  time  frame  pertaining  to  PDSS  would 
be  to  provide  for  the  inclusion  of  critical  PDSS  requirements  in  the  FY  83 
Command  Budget  Estimate  (CBE).  Note:  If  this  action  is  not  taken,  the 
alternative  is  to  defer  addressal  of  PDSS  requirements  until  development  of 
the  Program  Analysis  and  Resource  Review  (PARR)  for  the  FY  84-88  Program 
Objective  Memorandum  (POM). 

Action/event  11:  Submit  comments  to  CAC/CACDA  on  the  First  Draft  TRADOC 
PDSS  Regulation.  This  action,  applicable  to  all  TRADOC  elements,  is  to  be 
accomplished  in  response  to  Action/event  8. 

Action/event  12:  Submit  concurrence  or  comments  on  the  Draft  Implemen¬ 
tation  Plan.  This  action,  applicable  to  all  TRADOC  elements  involved  in  PDSS 
planning  is  to  be  accomplished  in  response  t:  Action/event  9. 

Action/event  13:  Submit  implementation  progress  reports.  This  action 
is  applicable  to  all  TRADOC  centers  and  schools  involved  in  the  execution  of 
this  plan.  Reports  will  be  submitted  in  accordance  with  instructions  in 
Paragraph  D-6. 

Action/event  14:  Prepare  material  for  the  Second  Formal  TRADOC  PDSS 
Review.  This  action,  involving  HQ  TRADOC  and  CAC/CACDA,  is  to  prepare 
appropriate  information  for  presentation  and  discussion  at  the  Second 
Formal  TRADOC  PDSS  Review  anticipated  for  late  July  1981. 

Action/event  15:  Conduct  the  Second  Formal  TRADOC  PDSS  Review  and 
receive  results.  This  action  involves  HQ  TRADOC  and  CAC/CACDA  with  partici¬ 
pation  as  appropriate  by  other  centers  and  schools.  One  of  the  major  objec¬ 
tives  of  this  review  would  be  to  obtain  approval  of  the  updated/revised 
version  of  this  Implementation  Plan. 

Action/event  16:  Develop  the  Second  Draft  of  the  TRADOC  PDSS  Regulation. 
This  action,  which  is  the  responsibility  of  CAC/CACDA,  will  be  initiated  follow 
ing  receipt  of  comments  resulting  from  Action/event  11. 

Action/event  17:  Prepare  the  Implementation  Plan  for  TRADOC  approval 
and  distribution.  This  action,  by  CAC/CACDA,  will  incorporate  results  of 
Actions/events  12  and  15  and  will  produce  the  final  version  of  the  Implemen¬ 
tation  Plan  for  TRADOC. 

Action/event  18:  Submit  CBE  input  pertaining  to  PDSS  requirements. 

This  action,  applicable  to  all  elements  of  TRADOC,  is  required  in  response 
to  Action/event  10.  Should  HQ  TRADOC  elect  not  to  proceed  with  Action/event 
10,  this  action  will  not  be  required. 
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d.  Phase  II  Actions/Events.  The  Phase  II  actions/events  discussed 
below  begin  in  late  August/early  September  1981  and  continue  into  March  1982. 

A  schedule  is  presented  in  Annex  III. 

Action/event  19:  Approve  the  TRADOC  PDSS  Implementation  Plan  for 
execution.  This  action  by  HQ  TRADOC,  marks  the  beginning  of  Phase  II  of  the 
implementation  effort. 

Action/event  20:  Distribute  the  Second  Draft  TRADOC  PDSS  Regulation. 

This  action,  by  CAC/CACDA,  will  initiate  final  coordination  of  this  key  regula¬ 
tion.  The  Second  Draft  will  incorporate  all  comments  resulting  from  action  on 
the  First  Draft  (Action/event  11)  and  will  provide  policy  guidance  relative  to 
PDSS  pending  finalization  and  distribution  of  the  approved  regulation. 

Action/event  21:  Submit  CBE  to  HQDA.  This  is  a  recurring  action  by  HQ 
TRADOC,  accomplished  as  part  of  the  TRADOC  Resource  Management  System.  This 
action  can  provide  for  the  addressal  of  PDSS  requirements  in  the  CBE  for 
FY  83  if  Actions/events  10  and  18  have  been  accomplished. 

Action/event  22:  Develop  and  submit  TDA  revisions.  This  action, 
applicable  to  all  elements  of  TRADOC,  is  a  recurring  action  accomplished 
generally  on  a  semi-annual  basis.  This  action  will  provide  for  reflecting 
in  TDA  documents,  organizational  changes  resulting  from  PDSS  Plan  implemen¬ 
tation.  If  TDA  revisions  are  not  required  at  this  time,  this  action  may  be 
deferred  until  the  next  periodic  TDA  update. 

Action/event  23:  Develop  input  for  the  TRADOC  Management  Information 
System  (TRAMIS).  Th"is  action,  applicable  to  all  TRADOC  elements,  provides 
for  intial  entry  of  PDSS-related  information  in  the  TRAMIS  data  base  in 
accordance  with  TRADOC  Regulation  71-1.  For  entry  into  TRAMIS,  PDSS  resources 
should  be  accounted  for  as  either  "PDSS  Management"  or  "PDSS  Execution." 

Within  the  latter  category,  resources  will  be  further  identified  by  battle¬ 
field  automated  system. 

Action/event  24:  Complete  detailed  implementation  plans  initiated  in 
Action/event  6.  This  requirement  is  applicable  to  all  elements  of  TRADOC 
impacted  by  the  Objective  PDSS  System  described  in  Annex  II.  These  plans 
will  be  in  consonance  with  this  basic  TRADOC  PDSS  Plan  and  specifically  with 
the  guidance  provided  in  Annex  IV.  They  will  be  coordinated  with  other 
elements  of  TRADOC  as  approparite.  One  copy  of  each  of  these  supplementary 
plans  will  be  provided  to  HQ  TRADOC  (ATTN:  ATCD-C-B  Mr.  Fallon)  and  one 
copy  to  CACDA  (ATTN:  ATZL-CAC-IA  Mr.  Schwabe). 

Action/event  25:  Distribute  instructions  to  all  TRADOC  elements  for 
Modernization  Resources  Information  System  (MRIS)  submissions.  This  is  a 
recurring  HQ  TRADOC  action  which  can  provide  for  the  development  and  sub¬ 
mission  of  PDSS-resource  data  for  inclusion  in  the  MRIS. 
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Action/event  26:  Submit  comments  on  the  Second  Draft  TRADOC  PDSS 
Regulation.  This  action  is  applicable  to  all  TRADOC  elements  in  response 
to  Action/event  20. 

Action/event  27:  Develop  final  copy  of  the  TRADOC  PDSS  Regulation; 
submit  to  HQ  TRADOC  for  approval.  This  CAC/CACDA  action  will  include 
resolution  of  all  comments  received  as  a  result  of  Action/events  20  and  26. 

Action/event  28:  Approve  and  publish  the  TRADOC  PDSS  Regulation.  This 
HQ  TRADOC  action  will  be  taken  following  receipt  of  results  of  Action/event 
27. 


Action/event  29:  Review/approve  and  submit  TDA  revisions.  This  is  a 
recurring  HQ  TRADOC  action  which  can  include  review/approval  of  TDA  document 
revisions  resulting  from  PDSS  implementation  actions  (i.e.,  Action/event  22). 

Action/event  30:  Initiate  action  to  enter  PDSS  workload  and  priority 
data  in  the  Priorities  and  Tasking  Control  (PTC)  Process.  This  action  is 
applicable  to  all  elements  of  TRADOC.  It  will  be  initiated  in  accordance 
with  procedures  prescribed  in  TRADOC  Regulation  11-2. 

Action/event  31:  Revise  HQ  TRADOC  and  center  and  school  mission  and 
functions  regulations  to  reflect  changes  required  by  the  TRADOC  PDSS  Reg¬ 
ulation  (Action/event  28)  and  to  show  changes  in  organizational  elements  and 
functional  responsibilities  resulting  from  PDSS  implementation.  This  action 
is  applicable  to  all  elements  of  TRADOC.  Copies  of  revised  local  regulations 
(e.g.,  10-1  regulations)  will  be  provided  to  HQ  TRADOC  in  accordance  with 
TRADOC  Regulation  1G-2. 

Action/event  32:  Submit  implementation  progress  reports.  This  action 
is  applicable  to  all  TRADOC  centers  and  schools  involved  in  the  execution 
of  uhis  plan.  Reports  will  be  submitted  in  accordance  with  instructions  in 
Paragraph  D-6. 

Action/event  33:  Prepare  material  for  the  Third  Formal  TRADOC  PDSS 
Review^  this  action,  involving  HQ  TRADOC  and  CAC/CACDA,  is  to  prepare 
appropriate  information  for  presentation  and  discussion  at  the  Third  Formal 
TRADOC  PDSS  Review  anticipated  for  late  November. 

Action/event  34:  Conduct  the  Third  Formal  TRADOC  PDSS  Review  and 
receive  results.  This  action  involves  HQ  TRADOC  and  CAC/CACDA  with  part¬ 
icipation  as  appropriate  by  other  elements  of  TRADOC.  The  purpose  of  the 
review  is  to  apprise  senior  officials  of  TRADOC  of  the  status  of  PDSS 
implementation  and  subsequent  plans  and  requirements. 

Action/event  35:  Develop  Memorandum  of  Agreement  (MOA)  with  associated 
material /system  developers.  This  action  is  applicable  to  all  centers  and 
schools  involved  in  this  implementation  effort.  The  development  of  this 


D-l  3 


MOA  will  be  one  of  the  detailed  implementation  actions  addressed  in 
supplementary  plans  to  be  prepared  (Action/event  24).  It  is  identified  here 
to  emphasize  its  importance  to  the  success  of  the  total  POSS  effort. 

Action/event  36:  Develop  and  submit  the  TRADOC  PARR.  This  is  a  re¬ 
curring  HQ  TRADOC  action  which  can  provide  for  addressing  TRADOC  PDSS  re¬ 
source  requirements  in  the  FY  84-88  POM. 

Action/event  37:  Issue  budget  instructions  for  the  FY  84  CBE.  This 
is  a  scheduled  HQ  TRADOC  action.  Instructions  issued  relative  to  PDSS  will 
depend  on  decisions  and  actions  taken  previously  in  connection  with  Actions/ 
events  10,  18,  21,  and  36.  If  PDSS  resources  were  not  addressed  in  Actions/ 
events  10,  18,  or  21,  this  will  be  the  initial  addressal  of  PDSS  resources  in 
a  budget  submission. 

D-5.  IMPLEMENTATION  SCHEDULE.  As  indicated  in  Paragraph  D-4,  the  initial 
implementation  actions  and  events  that  are  identified  herein  are  to  be  ac¬ 
complished  during  a  time  period  spanning  approximately  one  year  from  March 
1981  through  March  1982.  Other  actions  that  originate  from  these  initial 
actions  will  continue  on  for  several  years  before  full  implementation  is 
achieved  in  1987.  Throughout  this  time  and  beyond,  a  number  of  actions 
associated  with  the  TRADOC  Resources  Management  System  (TRADOC  Pamphet  11-11) 
and  the  Priorities  and  Tasking  Control  Process  (TRADOC  Regulation  11-2)  will 
be  accomplished  on  a  recurring  basis.  Due  to  their  nature,  some  of  the 
actions  identified  in  this  plan  were  completed  prior  to  its  final  approval 
and  distribution.  Verbal  authority  from  the  Commander,  TRADOC  provided  the 
basis  for  proceeding  with  these  preliminary  actions.  This  approved  plan  is 
the  authority  for  Phase  II  actions.  Annex  III  indicates  the  time  or  time 
period  when  each  principal  implementation  Action/event  is  to  be  accomplished. 
The  key  milestones  in  this  schedule  are  listed  below: 

DATE  OR  TIME  PERIOD  MILESTONE 

28  Feb  1981 


Late  Mar 
Late  May 


•  Receive  the  final  documentation  of  the  TRADOC 
PDSS  Study 

9  Conduct  the  First  Formal  TRADOC  PDSS  Review 

•  Distribute  the  First  Draft  of  the  proposed 
TRADOC  PDSS  Regulation  for  review 

t  Distribute  Draft  Implementation  Plan  for 
TRADOC  coordination 

•  Issue  FY  83  Budget  Instructions  for  PDSS 

9  Centers  and  Schools  Submit  Progress  Reports 

9  Conduct  Second  Formal  TRADOC  PDSS  Review 
9  All  TRADOC  elements  submit  CBE  PDSS  input 


Early  June 
Early  July 
Late  July 
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DATE  OR  TIME  PERIOD  MILESTONE  Continued 

Late  Aug/early  Sep  •  Distribute  approved  TRADOC  PDSS  Implemen¬ 
tation  Plan  (this  plan) 

Late  Aug/early  Sep  •  Distribute  Second  Draft  TRADOC  PDSS 

Regulation  for  review/coordination 

Sep  •  All  elements  submit: 

••  TDA  revisions  to  HQ  TRADOC  reflecting 

changes  resulting  from  PDSS  Plan  Implemen¬ 
tation  (Note:  This  action  could  be 
deferred  six  months  or  one  year  pending 
the  allocation  of  personnel  spaces  against 
PDSS  resource  requirements.) 

••  Prepare  PDSS  input  for  TRAMIS 

Late  Sep/early  Oct  •  Centers  and  schools  complete  supplementary 

detailed  implementation  plans 

Oct  •  Approve,  publish,  and  distribute  TRADOC 

PDSS  Regulation 

Nov  •  All  elements  develop  input  for  the  PTC  Process 

•  Centers  and  Schools  Submit  Progress  Reports 

•  Conduct  Third  Formal  TRADOC  PDSS  Review 

Feb  1982  •  Submit  TRADOC  PARR  reflecting  PDSS  resource 

requirements  for  FY  84-88  POM 

Mar  •  Issue  FY  84  budget  instructions 

D-6.  REPORTING  REQUIREMENTS.  Each  TRADOC  center  and  school  involved  in  the 
execution  of  this  plan  will  submit  implementation  progress  reports  to  be  used 
as  input  for  the  Second  and  Third  TRADOC  PDSS  Reviews  to  be  held  in  late  July 
and  late  November,  respectively.  These  reports  will  be  prepared  as  of  1  July 
and  1  November  and  submitted  to  HQ  TRADOC  (ATTN:  ATCD-C-B)  with  information 
copy  to  CACDA  (ATTN:  ATZL-CAC-IA) .  These  reports  will  be  submitted  to  reach 
TRADOC  and  CACDA  not  later  than  15  July  and  15  November.  Each  report  will 
provide  the  status  of  implementation  to  date,  major  problems  encountered, 
lessons  learned,  and  principal  actions  planned  to  continue  implementation 
efforts.  In  addition  to  these  scheduled  reports,  any  problems  encountered 
by  a  center  and  school  that  cannot  be  resolved  locally  will  be  submitted  for 
resolution  as  indicated  in  Paragraph  D-2.  Other  TRADOC  elements  will  submit 
information  as  requested  by  CAC  to  provide  input  to  the  periodic  Formal 
TRADOC  PDSS  Reviews,  or  to  satisfy  other  requirements  as  they  arise. 
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ANNEX  II 

THE  TRADOC  OBJECTIVE  PDSS  SYSTEM 

Note:  When  this  Implementation  Plan  is  prepared  in  final  copy,  this  Annex 
will  contain  a  description  of  the  TRADOC  Objective  PDSS  System 
structured  essentially  the  same  as  the  description  contained  in 
Chapter  2  of  this  Third  Interim  Technical  Report. 


ANNEX  III 

PRINCIPAL  ACTIONS  AND  EVENTS 

This  annex  presents  a  listing  of  the  principal  actions  and  events  that 
must  be  accomplished  during  the  initial  (approximately  one  year)  period  of 
the  TRADOC  PDSS  implementation  effort.  These  actions  and  events  are  presented 
in  tabular  form  on  the  following  pages  in  the  general  sequence  that  they  should, 
or  in  some  cases  must,  £>e  accomplished  for  proper  continuity.  Each  action/event 
is  identified  by  a  number  (corresponding  to  that  used  in  Paragraph  D-4  of  the 
basic  plan)  for  ease  of  reference.  The  TRADOC  element(s)  responsible  for  each 
action/event  i s/are  identified  and  the  products  or  results  of  each  action/ 
event  are  shown. 

The  time  period  when  each  action  is  to  be  initiated  is  also  shown.  These 
times  may  vary  depending  upon  future  decisions.  In  particular,  the  Phase  II 
actions  dealing  with  TDA  documents  may  be  deferred  six  months  or  one  year 
pending  the  allocation  of  personnel  spaces  against  PDSS  resource  requirements. 
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ANNEX  IV 


GUIDANCE  FOR  PREPARING 
CENTER  AND  SCHOOL  IMPLEMENTATION  PLANS 


1.  GENERAL. 

a.  Intial  Preparation.  Each  TRADOC  center  and  school  involved  in  the 
execution  of  this  Implementation  Plan  will  develop  a  supplemental  plan  to 
address  additional  details  not  covered  in  this  TRADOC  plan  and  unique  require¬ 
ments  that  must  be  considered  in  local  implementation  efforts.  Center  and 
school  plans  will  be  consistent  with  provisions  of  this  TRADOC  plan. 
Development  of  the  center  and  school  plans  will  begin  following  the  First 
Formal  TRADOC  POSS  Review,  scheduled  to  be  held  30  March  1981.  Planning 

will  proceed  based  on  guidance  resulting  from  that  review  which  CACDA  will 
forward  to  each  center  and  school  by  letter  in  early  April  1981.  Documented 
plans  will  be  completed  in  late  September/early  October  following  issuance  of 
the  approved  TRADOC  plan  (this  plan)  in  late  August  or  early  September. 

Copies  of  the  completed  center  and  school  plans  will  be  submitted  to  HQ 
TRADOC  (ATTN:  ATCD-C-B)  and  CACDA  (ATTN:  ATZL-CAC-IA)  not  later  than  15  Oct 
1981. 

b.  Update  of  Center  and  School  Plans.  The  supplemental  plans  prepared 
by  each  center  and  school  will  be  updated  annually,  coordinated  with  CACDA 
(ATZL-CAC-IA)  and  other  elements  of  TRADOC  affected  by  the  plan.  The  co¬ 
ordinated  plan  will  be  used  to  guide  the  implementation  effort  and  as  the 
basis  for  developing  inputs  to  the  TRADOC  Resources  Management  System. 

2.  STRUCTURE  OF  PLANS.  The  center  and  school  PDSS  implementation  plans 
will  be  organized  in  two  parts.  The  content  of  each  part  is  described  below: 

a.  Part  1— Management  and  Operations  Plan.  This  part  of  the  plan 
developed  by  each  center  and  school  will: 

(1)  Define  and  provide  a  time-phased  schedule  for  the  actions  that 
must  be  accomplished  to  acquire,  install,  interface,  operate,  manage,  and 
maintain  the  PDSS  capability  called  for  in  the  TRADOC  Objective  PDSS  System. 

(2)  Describe  in  detail  the  resources  required,  quantity  and  type  of 
personnel,  contractual  support,  type  and  quantity  of  equipment,  physical 
facilities  required,  and  physical  and  other  interfaces  with  associated  MD 
PDSS  center(s),  training  developer  facilities,  test  activities,  and  indepen¬ 
dent  user  tester(s). 

(3)  Describe  the  required  analytical  and  test  tools,  devices,  and 
models  necessary  to  support  new  requirements  or  refinements  of  software  in 
the  BAS  within  the  respective  BFAs. 

(4)  Describe  simulation  models  required,  their  interfaces  or  re¬ 
lationships  with  existing  models,  and  planned  steps  for  acquiring  these 
support  tools. 
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b.  Part  2--Fiscal  Plan.  This  part  of  each  plan  will  contain  a  projection 
of  funding  required  by  type  and  amount,  by  fiscal  year,  for  the  current, 
budget,  and  program  years,  to: 

(1)  Implement  the  Objective  PDSS  System  at  each  center  and  school 
invloved  with  this  system,  and 

(2)  To  provide  PDSS  for  the  BAS  for  which  each  center  and  school  has 
combat  developer  proponency.  This  funding  projection  will  include  estimates 
of  costs  for  user  tests  and  other  testing  for  which  the  combat  developer  is 
responsible. 


